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

[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 (非公式)

[anatawa12]

需要として想定されそうなものという意味ではリモートのチャンネルをフォローしたいという需要はありそう。

すぐにやらなくてもこれを想定した実装にしたい気がする

[KisaragiEffective]

リモートのチャンネルをフォローしたい

実は #11400 で既出

[KisaragiEffective]

今までのAPIとの一貫性を考えると、リモートユーザーのように「リモートチャンネル」という概念を生やす必要がありそう

[KisaragiEffective]

リモートチャンネルを生やすとUpdateコマンドを送信するべきだが、そのペイロードはカスタムになってしまうのでは…？

[Sayamame-beans]

Misskeyのファイルの連合に近い話…?

[KisaragiEffective]

アレはattachmentsでなんとかごまかせるけどこれはそうもいかない

[syuilo]

チャンネルの管理者のアカウントがあるサーバー自体が閉鎖した際に残されたチャンネルはどうなるのかしら

[KisaragiEffective]

XにA以外から書き込めるような拡張をするのは考えていなかった
(面白そうだけど多分割に合わない)

[anatawa12]

チャンネルの主のサーバーに連合できなければ(チャンネル主のサーバーがsuspendされてれば)そのチャンネルに投稿を禁止するべきではありそう

Deleteコマンドを連合先に配るだと負荷が高そうなので、手元のサーバーから配送して410が出たときにアーカイブされたフラグを立てるのほうがいいかも

にかぶるけど

[anatawa12]

XにA以外から書き込めるような拡張をするのは考えていなかった
(面白そうだけど多分割に合わない)

リプライの処理で多分必要になりそう

[Sayamame-beans]

誰もフォローしていないリモートのチャンネルへは投稿不可にする…?

チャンネルをフォローすることでチャンネルの情報を得るという前提に立つと、B,Cの誰かがXをフォローしていればチャンネルがアーカイブされたことを知る術がある(投稿可否が分かる)ので…
(場合によってはproxyアカウントにフォローさせられるかも)

しかしこれだと、リプライしたくなった時に困りそうですね…

[Sayamame-beans]

#14030 と同じ感じで、"届かない可能性がある"を示すと多少は良さそうですかね?

[syuilo]

Aサーバーで作られたチャンネルXがBサーバーとCサーバーにも連合されていて、ＸにＢのユーザーが投稿したときにＡはＣに対してアクティビティをリレーするような形になる？

[KisaragiEffective]

多分そう (#11400 で軽量なリレーじゃない？という指摘が入っている)

[Sayamame-beans]

"チャンネルをフォローする"ことでそのチャンネルの投稿を拾う形を取ると、そのようになりそうです
(フォローしていない場合は、リモートの投稿同様、(ユーザーの投稿として拾うことで)観測したものだけ…)

[Sayamame-beans]

チャンネルのアーカイブ仕様メモ

• 当該チャンネルは検索に含まれないようになる
• 直接アクセスは可能
• タイムラインは(長期間経つと)そのうち見られなくなる
• チャンネル内への新規投稿(リプライ含む)が不可に
• チャンネル内のノートは消えない
• リアクションは可能
• チャンネル外へのRNや引用は可能
• チャンネル外からチャンネル内のノートを引用したものに対しては、アーカイブ後もリプライ等可能

[Sayamame-beans]

• アーカイブ化は(API経由で)解除出来る
  (この挙動はお知らせのアーカイブ化と同様)

[KisaragiEffective]

cf. https://codeberg.org/fediverse/fep/src/branch/main/fep/1b12/fep-1b12.md

[KisaragiEffective]

https://misskey.niri.la/notes/9vqs1vadvu

流す情報の必要性についてスコープや見通しが立っていないからめちゃめちゃ適当だけど、とりあえずチャンネル情報を向こうに流したいよねってことは一致してそうなので、ひとまずFEP-1b12をシカトしてtype: "Note"なIObjectに_misskey_channel: MiChannelを増築することになりそう

[tai-cha]

これに関してはFEP-1b12をシカトしなくてもFEP-1b12の拡張でもできそうなのでシカトすると決めるには早いかもしれない？

Ordinaly posted in: https://mi.taichan.site/notes/9vqsczqqa4

[tesaguri]

チャンネルのノートを連合なしにするという現在の仕様に至った理由がチャンネルのノートの文脈がチャンネル内に閉じているであろうからというものであったこと（#6669）を踏まえると、チャンネルを連合させるに当たってチャンネルのノートを照会したときにそのノートがどのチャンネルに宛てたものであるかが分かるようになっているのが望ましいと思います。これについてはFEP-1b12で規定されているように、Noteのaudienceプロパティでチャンネルを指定することで素直に実現できるかと思います。

これをさらに飛躍させたアイデアとして、完全なチャンネルの連合機能を実装する前にこの文脈指定の機能のみを実現できるのではないかといったことを考えています。具体的には、inboxを持たない（つまり、リモートからのフォローを受け付けない）Groupとしてチャンネルのメタデータのみを連合して、NoteのaudienceプロパティでそのGroupを指すといった感じです。将来的に完全なチャンネルの連合機能が実現した場合はこのGroupにinboxを生やすことで"不完全な"チャンネルと区別できるでしょう。飛び道具的な対応という感は否めませんが、もしこれが実現すればチャンネルのノートを連合なしにする現在の制限を早期に緩和できるのではないかと思います（#10710）。

[tai-cha]

チャンネルに関しては全体のモデレーション責任をチャンネルを保有するインスタンスが行うのかあくまでノートを発行するインスタンスが行うのか、その両方なのかに応じて（チャンネルからの）ノートの削除が可能なインスタンスを考えるなどの観点も必要そうな気がしてきました

[KisaragiEffective]

misskey-dev/misskey-hub-next#289
ひとまずたたき台