atprotoモデレーション概論 基礎編
ここでは、atproto仕様上モデレーションがどのような形で表れるかについて説明する。基本的には公式ドキュメントにある内容。
bsky固有の仕様やlabelについては別記事。
atprotoの構造とモデレーション
まず前提として、atprotoにおけるデータフローは以下のようになっている。[^network]
[^network]: relayもappviewも単一である必要は無いが、現状はほぼ単一で、かつ増やしても説明上はあまり意味が無いため、ここではこれくらいにしておく。
atprotoのモデレーションは基本的に、この中のどれかが出力をマスキングするという形で実現される。
ただし実のところ、この文脈においてappviewとrelayを区別する必要はあまり無いので、以降はrelayを省略する。[^relayapp]\ 今のところrelayにおけるモデレーションらしき例も(アカウント数制限くらいしか)聞かない。
[^relayapp]: relayは必須の存在ではなく、appviewが直接クロールしてもいいし、新しいrelayを勝手に立ててもいい。もちろん既存relayに便乗した方が楽だし、relayはPDSからの通知を受けられた方が効率良くなるが、いずれも必須ではない。relayでマスクされたところで、repositoryの一部だけであれば、署名検証で検出してPDSに直接取得しにいけばいい。
現状のBluesky Socialで一般的に「モデレーション」と呼ばれるものは、概ね以下のいずれかの形で表れる。後のものほど強い。
クライアントによる表示のマスキング appviewによるAPIレスポンスのマスキング PDSによるAPIレスポンス・firehoseのマスキング PDSによるアカウント削除
それぞれ判断材料は他所(labeler等)から提供される場合があるが、話がややこしくなるため後に回して、最終判断を下す主体から一通り説明する。
様々なモデレーション
クライアントによるマスキング
Bluesky利用者に一番馴染み深いのはやはりこれだろう。画像の警告とかワードミュートが該当する。別途説明するlabel周りは大体ここで処理される。
閲覧側クライアントが各データの表示を制御する。基本的には利用者個々人の設定次第だろうが、クライアントによって強制される場合もある。\ 例えば、公式クライアントはプラットフォームの規約上、誕生日を登録しないと性的コンテンツが表示できないようになっていたはず。
強制の場合、クライアントを変えてどうにかなるかは微妙なところ。設定可能な範囲に関しては個々の利用者次第だ。
appviewによるマスキング
一般にBANと呼ばれる、「Account has been suspended」というやつは大体これ。atproto的にはtakedownと呼び、APIレスポンスから対象アカウントが除外される。\ モデレーションと呼ぶかは微妙だが、ブロックやアカウントミュートもここ。
特定のコンテンツ(record/blob)だけtakedownする場合もある。実例は見たことないが、DMCA対応とかはこれになるだろう。
回避するには異議を申し立てるか、別のappviewを使おうという話になる。ただし、appviewを変える必要があるのは、takedownを受けた側ではなく見る側である点に注意。アカウントごとtakedownを受けた場合、事後に代わりのappviewについて伝えるのは難しいかもしれない。また、今のところ既存appviewの代替を提供する人はいないので[^altappview]、そこは自力でなんとかするしかない。
[^altappview]: コストや技術のハードルがあると思われるが、そもそも試み自体がほぼないので何とも言えない。やるとしたらそれこそモデレーション回避目的の可能性が最も高そう。
appview単位なので、例えばBluesky SocialでtakedownされてもWhiteWindには影響無い。[^appviewmod]
[^appviewmod]: 現実はもう少し面倒で、例えばWhiteWindのコメント欄はBluesky Socialに依存しているし、PDSのtakedownが同時に発生したりする。
PDSによるマスキング
発信側PDSもappviewと同様、所属アカウントやそのコンテンツにtakedownを行うことがある。根本を止められるので、appviewによるものより強い。\ 閲覧側PDSは一応経路になってこそいるが、基本的に素通しなので無視していい[^pdsmoderation]。
[^pdsmoderation]: 細かいことを言えば、受信側PDSがここに干渉することもできる。ただし、そのためには対象APIを知っており、対応ロジックをPDSに実装する必要がある。一般に、PDSはlexicon非依存であり、PDSの知らないAPIを仲介することがあるため、PDSが完全にコントロールすることは原理上困難と思われる。
公式PDS(bsky.social)では、公式appview(api.bsky.app)のtakedownと同時にPDSでもtakedownされるのが一般的。詳細はBluesky Socialの話をするときに。
PDSにtakedownされ、解除してもらう見込みもない場合、PDSを引っ越すことになる。幸い、takedownされても引越用の機能(データのエクスポート等)は利用可能だが、現状引越機能はユーザーフレンドリーとはとても言えないので、受け入れてくれるPDSが見つかっても尚ハードルが高いかもしれない。[^pdsimport]\ また、PDSのtakedownがappviewに反映されたあとに引っ越した場合、ちゃんと解除できるかは実装依存。
[^pdsimport]: 細かいことを言うと、実装上の問題により、公式PDSへの引越し(というかデータのインポート)は禁止されているが、この文脈では基本的に出ていく方なので、問題になることはないだろう。
PDSによるアカウント強制削除
一番重い。事例あり。
全部消えるので、事前にバックアップ等の準備をしていなければ、データの持ち出しどころか引越しもできない。
おまけ
モデレーションと呼ぶかはともかく、「情報のフィルタリング」という観点では他にも何箇所かで起きている。
太字はフィルタリングする主体。
client->PDS lexiconのバリデーションや、データサイズ・レート制限がこれ。 PDS管理者の権限によってアカウントが削除される可能性もある。 PDS->relay PDSは特定のアカウントやデータを渡さない場合があり、(PDSによる)takedownと呼ばれる。 特定relay以外のクローリングを拒否する可能性もあるが、現状一般的ではない。 PDS->relay そもそもどのPDSをクローリングするかはrelayが決めるものだが、各PDSのfirehoseから特定のアカウントを無視することもある。 基本的にアカウント単位より小さくならないし、仮になってもappviewによる検出・回避は比較的容易。 2024年前半にあった、サードパーティクライアントに対する1PDS10アカウント制限がこれ。 relay->appview PDSのtakedown通知を受けて出力をマスクすることがある。 今のところ無いが、DID認証で行儀の良いappviewのみ許す、といったことも可能。 relay->appview firehose上から必要なデータを選別する。 bsky appviewがpostの上書きを無視するとか、whtwnd entryを無視するとか。 appview->PDS lexiconの示すスキーマにさえ従えば大体なんでもできる。 appviewによるtakedown・labelによるフィルタリング・ミュートやブロックの反映等 client->user
- 特定labelの非表示やスレッドミュート等
ちなみに、矢印の一方だけしかモデレーションしない場合、もう一方は大体主体的に通信相手を選べる。どのクライアントを使うかはユーザの自由だし、どのrelayからデータを取得するかはappviewの自由だ。