コンディショナルロールの付与条件増強

[samunohito]

Summary

以下を新たな条件として設定できるようにします。

• ドライブの使用容量（DriveFileEntityService#calcDriveUsageOf）
• botかどうか（user.isBot）
• サスペンドされているか（user.isSuspended）
• ユーザ情報の更新日時（user.updatedAt）
• セキュリティキーの有無（userEntityService.packのsecurityKeysと同じ条件）
• email認証済みか否か（user_profile.emailVerified）
• 2fa設定済み（user_profile.twoFactorEnabled）
• パスワードログイン設定済み（user_profile.usePasswordLessLogin）

Purpose

• ロールにより制御可能な機能の恩恵と各値を結びつけることによるモデレーションコストの軽減
• バッジの付与で2fa設定の促進…みたいなのにも使えるかも？

Do you want to implement this feature yourself?

• Yes, I will implement this by myself and send a pull request

[samunohito]

他にもコレが欲しい等あればここに書き込み願います

[samunohito]

（ほかにもいくつか抱えてるので実際の着手はしばらく後の予定）

[Sayamame-beans]

partially duplicate of #9545
a bit related to #13351 ? (既にマニュアルロールへのアサインを条件に出来るようになっているため、認証系の条件が増えた場合、2ロール使えば近いことが出来そう)

[meronmks]

• 「投稿数が～」があるので似たようなノリで「リアクションした数が～」「リアクションされた数が～」
  • 集計で負荷がそこそこありそうなのが懸念点？
• 設定された誕生日かどうか
  • 誕生日限定ロールやバッジ付与に使えそう

[Sayamame-beans]

• 通算ログイン日数
  • 実績のために恐らく既に存在するデータ
  • ユーザーがどのくらい利用しているかがノート数よりも測りやすいかも?
  • (ROM専かどうかはノート数で分かる(ただしRNしかしていないようなケースもあり得そう。これは判断出来ない))

[Sayamame-beans]

リノートの数、アカウントの統計情報にあったんですね(リアクションは記憶していましたがリノートやそれ以外のもは覚えてないです)
統計情報って本家だと無くなってるんでしたっけ…?

[syuilo]

本家以外でもリノート数などをデータベースに持っている実装は無いと思う

[Sayamame-beans]

本家以外でもリノート数などをデータベースに持っている実装は無いと思う

ioにはあると耳にしています
MisskeyIO#258

[syuilo]

本家以外でもリノート数などをデータベースに持っている実装は無いと思う

ioにはあると耳にしています MisskeyIO#258

特にデータベースは変更してなさそう

[Sayamame-beans]

ありませんか…?

https://misskey.niri.la/notes/9rr7vkanhl より

[syuilo]

都度集計してるだけでデータベースにはなさそう

[Sayamame-beans]

都度集計してるだけでデータベースにはなさそう

なるほど、そういうことでしたか…

[samunohito]

以下で実装します。

• ドライブの使用容量（DriveFileEntityService#calcDriveUsageOf）
• botかどうか（user.isBot）
• サスペンドされているか（user.isSuspended）
• ユーザ情報の更新日時（user.updatedAt）
• セキュリティキーの有無（userEntityService.packのsecurityKeysと同じ条件）
• email認証済みか否か（user_profile.emailVerified）
• 2fa設定済み（user_profile.twoFactorEnabled）
• パスワードログイン設定済み（user_profile.usePasswordLessLogin）
• 設定された誕生日かどうか （user_profile.birthday）
• 通算ログイン日数（user_profile.loggedInDates.length）
• リアクションした数（note_reaction.userId）
• リアクションされた数（note_reaction + note.userId）
• リノートした数（note.userId + note.renoteId IS NOT NULL）
• リノートされた数（note.renoteUserId）
• リプライした数（note.userId + note.replyId IS NOT NULL）
• リプライされた数（note.replyUserId）
• 投票した数（vote.userId）
• 投票された数（vote + note.userId）

[syuilo]

〇〇した数系はデータベースに持っていない(もしくは持ってても精度が低い)のがほとんどで、コンディショナルロールで使うのは現実的ではないかも

[syuilo]

どうしても使いたい場合は、データベースにカラムとして持つようにした上で、PostgreSQLのトリガ定義してカウントするようにした方が良さそう

[samunohito]

〇〇した数系はデータベースに持っていない(もしくは持ってても精度が低い)のがほとんどで、コンディショナルロールで使うのは現実的ではない

負荷の面で負担になりそうな懸念はたしかにあります。
数十万件のレコードを作ってみて、実際に動かしたときの挙動次第で判断しようとしていました。

完全にオミットするか、コンディショナルロールの算出結果をCacheServiceよろしく特定期間保存するか…

[syuilo]

コンディショナルロールの判定は場合によっては大量に行われるから同期的な処理だけで済ませたい

[samunohito]

同期的な処理だけで済ませたい

これはPromiseを使わずに実現できる範囲であればOK…ということでよいです？

[samunohito]

結果のキャッシュやジョブで付与したものを取り出すだけにするのでも厳しいでしょうか…？
同期限定だと、今後登場するであろう別の条件の選択肢も狭まってしまうので

[syuilo]

コンディショナルロールは参照される機会が桁違いに多いからキャッシュする場合短時間でも数千とか数万の量になってメモリ的に厳しそう

[syuilo]

同期的な処理だけで済ませたい

これはPromiseを使わずに実現できる範囲であればOK…ということでよいです？

そうね

[samunohito]

（ちなみに、コンディショナルロールのアサインをDBに持たず都度判定してるのって何か歴史的経緯があるんでしょうか？）

[syuilo]

（ちなみに、コンディショナルロールのアサインをDBに持たず都度判定してるのって何か歴史的経緯があるんでしょうか？）

#12563 (comment)

[samunohito]

あるユーザーが与えられた際にそのユーザーが条件に合致するか判定しロールを算出

なぜこうなっているのか知りたく

[syuilo]

例えるなら、地球上からランダムに人をピックアップしてその人が男性か女性かを判定することは容易でも、地球上のすべての男性もしくは女性を列挙するのは不可能(一人一人調べていたら途方もない時間がかかるから)という感じです

が理由

[Sayamame-beans]

データベースに存在するすべてのユーザーに対して条件に合致するか都度調べる必要があり

条件の判定が最短で1回/日や1回/週となるようなキャッシュ保持を検討することは困難なのでしょうか?
(ユーザーごとに「そのユーザーに対してコンディショナルロールの条件が最後に確認された日」を保持し、そこを見てexpiredなら今と同じように全コンディショナルロールを再チェック、期間内ならマニュアルロールと同じようにロールキャッシュから取得)
(もちろん、コンディショナルロールに毎秒レベルの精度が必要であればこの案は不可能ですが…)

[syuilo]

条件の判定が最短で1回/日や1回/週となるようなキャッシュ保持を検討することは困難なのでしょうか?

#13667 (comment)

[Sayamame-beans]

日付情報1つをuserと同様に常に持っておくことによる参照負荷はそれほど高いものなのでしょうか…?

[syuilo]

日付情報だけでなく、ロール情報もキャッシュが必要じゃないかしら？
その場合、メモリ負荷は高くなるわね

[syuilo]

コンディショナルロールはどんなリモートユーザーにも無条件で適用されるという点は留意しないといけない

[syuilo]

適用されるコンディショナルロールが無いということもキャッシュしなければならないから最大で全てのFediverseユーザーに対してのキャッシュが必要になる

[samunohito]

あ～

[Sayamame-beans]

ふむ…では、ローカルに限ったり出来るなら(出来ないかも)少し話が変わる感じでしょうか?

逆の、ロール側ではなく情報側を持つ方向で検討する場合は、個人的には

email認証済みか否か
2fa設定済み
パスワードログイン設定済み
通算ログイン日数

はロールの条件として利用する価値が十分高いと感じているのですが、それらの内容も現状user_profile内にあるため、更新頻度(少ない)によらず厳しいということですよね…
(userと一緒に持つように変更するなどの迂回策は、恐らくuserは他の処理と併用していると思うので、何らかの処理の際に本人以外のユーザーに見えてしまう危険性がありますかね?)

[syuilo]

ふむ…では、ローカルに限ったり出来るなら(出来ないかも)少し話が変わる感じでしょうか?

ローカルに限ったとしてもユーザー数が多い場合結局はメモリの問題が出てくるわね
適用されるロールが無い場合も無いという情報をキャッシュしなければならないというのが他のキャッシュと比べてメモリを圧迫する理由のひとつ

逆の、ロール側ではなく情報側を持つ方向で検討する場合は、個人的には

それらはuserで持つようにしても良さそう
ただ連続ログイン日数は実装が難しそう

[Sayamame-beans]

ただ連続ログイン日数は実装が難しそう

(現存しない"連続"ではなく、現存する"通算"の日数です)

[syuilo]

通算日数は保持してなくて、厳密にはログインした日付の配列だったと思う

[Sayamame-beans]

確かに、上にuser_profile.loggedInDates.lengthと書いてありましたね…見落としていました

[samunohito]

諸々了解しました。コンディショナルロールについては「非同期なく即時判定可能なもの」で実装します。

[samunohito]

（off-topic）
以下のような前提付きの「特定条件により自動的に付与・剥奪されるマニュアルロールに近いもの」とかだったら検討の余地ありだったりします？

• ローカルユーザ限定
• 処理上の振る舞いとしてはマニュアルロールに準拠（role_assignmentで管理）
• ジョブで定期実行し、そのうえで判定される（実行間隔は設定可。OFFも可）
• 全ユーザを一気にやらずに小出し（1回で処理する人数は設定可）で判定する

role_assignmentのレコード数は増えますが、逆に言えばそれだけだと思うので…

[syuilo]

実際そのようなものは考えてたし検討の余地はあるわね
あとMisskey本体での実装ではなくても既に外部ツールとして特定条件を満たしたユーザーに自動でマニュアルロールを付けたり外したりするものもある
Misskey本体での実装を考えると現状コストに見合う需要はないかも

[samunohito]

なるほど、ありがとうございます。需要が見込めたら別途issueを建てようと思います。