チャンネルの連合処理を実装するに当たって考えるべきことを整理するためのissue

[KisaragiEffective]

Summary

整理の目的

以下の2つをメインに考えたい

• リモートのチャンネルに対するモデレーションとして何がほしいか
• リモートのチャンネルへの投稿が連合された場合、どのような情報がほしいか

このissueを書いた時点での自分の見解

• チャンネルの連合処理 → チャンネル管理者による選択式が望ましそう (related: チャンネルノートの連合有無を切り替えられるようにしてほしい #10710)
  • デフォルト: 今までどおり連合させず、localOnly = true を強制する
  • 想定
    1. 「連合ありノートを許可する」スイッチを新設
    2. チャンネル管理者がオプトインする
    3. 投稿者は連合ありが許可されている場合連合ありノートをできるようになる
• チャンネル自体の情報の連合 → あってほしそう
  • 想定ケース: isSensitiveが立っているチャンネルの場合、LTLに露出させたくない (cf. c2383fa)
• 同時に追加したほうが良さそうな機能
  • backend: 流入してくるチャンネルへのモデレーション機能としてサーバー管理と同等の機能を追加すると良さそう？
    • チャンネルをサイレンス → チャンネルを強制的にホーム送りにする
    • チャンネルの連合をカット → そのチャンネルで行われたノートをすべてドロップ
  • frontend: チャンネルからのノートは${チャンネル名} from ${インスタンス名}のように、他のインスタンスから流れてきたことがわかるラベルをつける (デザイン案1)

このissueを閉じるべきとき

• ソフトウェアとしてチャンネルの連合処理を実装しないという判断がされた場合 (ref. チャンネルのモデレーション #10637 (comment)) → 今も変わりはない？
• チャンネルの連合処理が一応実装された場合
  • 実装後の新規機能追加要望などはissueのスレッドが散らかるので個別にissueが立てられるべき

添付ファイル

デザイン案1: チャンネルに投稿されて連合されてきたノートがフロントエンド上でどのように表示されるべきか

cc #8475 #11400

Purpose

適当に実装するとやばそうなので実装前に意見を募集したい (実装できるとは言っていない)

Do you want to implement this feature yourself?

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

[KisaragiEffective]

prior discussion: https://misskey.niri.la/notes/9uq9bdz57h and its subtree (非公式)