通報を受けた時の通知機能を拡充する

[samunohito]

Summary

サーバのユーザから通報を受けた際、モデレータがそれを知る手段が乏しく以下に限定されています。

• meta.email に登録されているメールアドレス
• Streamのadminチャンネルを購読しているクライアント（Misskey本体には使ってる場所が無い？）
• モデレータ自身がコンパネを目視で監視する

迅速なモデレーションを行うために、通知機能（とその付帯機能）の拡充をした方が良いと考えました。
具体的な案としては以下のようなイメージです。

• meta.emailだけではなくモデレータにもメールを送信
• モデレータがログインした瞬間に気づけるような仕組み
  左部メニューにあるコントロールパネルのインジケータ点灯など
• 通報をすぐに開けるURLの発行とフロント側のルーティング
• webhookでの通知
  連携先は無限に考えられるので、必要な情報を変数として提供し、それを使ってペイロードのテンプレートを記述してもらうようなイメージで考えている

～↓も考えたけど微妙かも？～

• モデレータへのDM（rootアカウント→アカウントのDMと任意ののAP連合先アカウント）
• PWA/ブラウザでの通知

通報がひっきりなしに来るようなシチュエーションも考えられるので、メール・webhook・DM・ブラウザ/PWAでの通知をそれぞれOFFに出来るようなオプションもあると尚良いと思います。

Purpose

• モデレータが通報に気付きやすくなり、サーバの治安悪化を最小限に抑えられる

Do you want to implement this feature yourself?

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

[syuilo]

通報の対処が必要になる規模のサーバーの運営者はSlackやDiscordを使っている場合がほとんどだからwebhookがあれば良さそう

[samunohito]

やるか…

[samunohito]

今回やる予定のやつ

• meta.emailだけではなくモデレータにもメールを送信
• webhookでの通知
• 通報をすぐに開けるURLの発行とフロント側のルーティング

インジケータ表示も要望あったけど別途やる。
通報の有無を含めて通知表示が4種類あり、これらも含めたほうが良いかどうか検討したいので

misskey/packages/frontend/src/pages/admin/index.vue

Lines 15 to 18 in 860e8bb

	<MkInfo v-if="thereIsUnresolvedAbuseReport" warn class="info">{{ i18n.ts.thereIsUnresolvedAbuseReportWarning }} <MkA to="/admin/abuses" class="_link">{{ i18n.ts.check }}</MkA></MkInfo>
	<MkInfo v-if="noMaintainerInformation" warn class="info">{{ i18n.ts.noMaintainerInformationWarning }} <MkA to="/admin/settings" class="_link">{{ i18n.ts.configure }}</MkA></MkInfo>
	<MkInfo v-if="noBotProtection" warn class="info">{{ i18n.ts.noBotProtectionWarning }} <MkA to="/admin/security" class="_link">{{ i18n.ts.configure }}</MkA></MkInfo>
	<MkInfo v-if="noEmailServer" warn class="info">{{ i18n.ts.noEmailServerWarning }} <MkA to="/admin/email-settings" class="_link">{{ i18n.ts.configure }}</MkA></MkInfo>

[syuilo]

メールで受け取るかどうかはオプションにする必要があるわね
規模が大きいとものすごい量の(対処不要な)通報がくるため

[samunohito]

webhookにも同様のことが言えると思うので（というかそういう話を聞いたので）、ここで追加するものはon/off切り替え可能なように実装します。

[samunohito]

連携先は無限に考えられるので、必要な情報を変数として提供し、それを使ってペイロードのテンプレートを記述してもらうようなイメージで考えている

これは下記の理由からやめる。ペイロードの形式は固定で。

• 脆弱性を作りこみそうで怖い
• 既存のWebhook送信の仕組みを流用したい
• アプリとしての責任範囲を最小にしたい（参考：GitHubやBacklogなど、大手が提供するサービスの実装の大半は固定）

[samunohito]

管理系のwebhookを持つテーブルを新設して、その上に通報のwebhook機能を載せるような感じで考えている
（送信は既存のwebhook送信の仕組みを間借りするようなイメージ）

[syuilo]

管理系のwebhookを持つテーブル というと？

[samunohito]

管理系のwebhookを持つテーブル

もともとあるwebhookテーブルではなく、システム契機で作動するwebhookを登録しておくためのsystem_webhook（仮）を作ろうとしていました。システム契機の場合はユーザIDを持たず、またイベントの種類も既存のwebhookとは異なるため、既存のものと混ぜたくないなという思いから。

[syuilo]

ほむん

[samunohito]

通報をすぐに開けるURLの発行とフロント側のルーティング

通報一覧画面に対象のIDを引き込めても、バックエンド側との噛み合わせがイマイチで難しいのでいったんオミットする
（対象IDをピンポイントで取得する機能が無い）