misskey-dev
センシティブ判定を外部サービス扱いにする
Summary
summalyみたいにURLを設定してそこにリクエストする形式にする
Purpose
- nsfwjsはスクリプトサイズ的にもメモリ使用量的にもヘビーなため、外部化できれば本体の必要要件を緩和できる
- センシティブ判定機能を使用しないサーバーで無駄にストレージ/メモリを消費することがなくなる
- nsfwjsに起因するトラブル(Misskeyのインストールに失敗する、メモリリークする等)に影響を受けなくなる
- APIさえ同じであれば、nsfwjs以外の(より効率的な)実装を運営者の好みに応じて選択することもできる
Do you want to implement this feature yourself?
- [ ] Yes, I will implement this by myself and send a pull request
nsfwjsはスクリプトサイズ的にもメモリ使用量的にもヘビーなため、外部化できれば本体の必要要件を緩和できる nsfwjsに起因するトラブル(Misskeyのインストールに失敗する、メモリリークする等)に影響を受けなくなる
一応確認ですが、Misskey本体から完全に切り離す方向性です？
実装を進める傍ら、下記も併せて考えたい気持ちがある（今使ってる人が混乱しないようなフォロー）
- Misskey本体コンパネのセンシティブ判定設定部分にMkInfoを置いて外部化されたこと、分離した機能のセットアップがべと必要なことを明記
- CHANGELOG.mdのNote項目への記載を厚めに
あと、分離先でも…
- 分離したリポジトリ側のREADME拡充（セットアップ方法、Misskey本体への設定方法など）
I suggest if possible this be done with an asynchronous API. I.e. one for pulling a list of media without a classification, one API for setting the results of the classification, both are easy to do with DB and decouples heavy computation of classification from the state management loop.
Otherwise it might be a little .. shifting load to something "external" but not really reducing latency or increasing flexibility.
I think I meant partly considering relaxing the consistency requirement here, if the design is such that every single media has to come in, block the current federation job, get a result from a likely computationally heavy function (whether built into misskey or an external synchronous API), it likely does not reduce the process latency and causes more availability problem (what to do if the API call fails?).
Since there is no 100% recall algorithm for detecting "sensitive media" nor will there ever be in the near future, I think it is okay to let a post go through first and then later we can update its media to be sensitive if needed asynchronously, like most moderation work is - the goal is be scalable and minimize disruption.
センシティブフラグの付与を非同期的にするかどうかは外部サービス化とは異なる関心なので、別Issueの方が良さそうです ここで非同期化の懸念について少し書くと、非同期の場合判定が完了する前にユーザーが投稿できてしまうことにならないかしらという点です
It's okay we can leave asynchronous on hold first but I believe fault tolerance should be a concern here - what happens if the API call fails? Should we just stop everything or have some other strategy?