atprotoモデレーション概論 実践編

atprotoモデレーション概論 実践編

atprotoモデレーション概論 目次

望まれることの多い独自モデレーションの実現案について考えてみる。
あくまで一案に過ぎないし、本当に実現できるか検証したわけでもないが、何かの参考にはなるかもしれない。

問題設定

atprotoのモデレーション周りで期待されることが多いのは、「日本独自のモデレーション基準を適用したい」というものだろう。

labelに関して言えば、独自モデレーションは特に難しくない。緩めるには見る側がクライアント設定で外せばいいし、強めるにはlabelerを運用すればいい。

問題になるのはtakedownやアカウント削除される場合だろう。Bluesky Socialの禁止行為には以下のように書かれており、特に抵触しやすそう。

Distribute child sexual abuse material, or any content portraying minors in a sexually explicit context

似たような規約はよくあるが、日本はこの手の表現に比較的寛容と言われている。
国内でのみ許されるようなコンテンツを投稿した結果、規約違反としてアカウントごとtakedownされれば、その他の問題無いコンテンツも含めてBluesky Socialから追い出されてしまう。この辺りが、(「追加の」ではなく)独自のモデレーションを望む背景にあるだろう。

とはいえ、Bluesky Socialへの依存を完全に排除するのも(プロトコル的には王道だが)未だ現実的ではない。PDSはセルフホストすればいいが、appviewはそうもいかない。
Bluesky Social利用者の投稿も見たいなら、公式appviewのクローンを作る必要がある。つまりおよそ2000万人分(2024年時点)のデータを取り扱う必要があり、月額4桁ドルはかかると言われている。小規模なコミュニティで使いたいだけなら、あまりに過剰だ¹。
そうでなくとも、Bluesky Socialから見える状態が作れるのであれば、それに越したことはないだろう。

ということで、その場しのぎ感は強いが、なるべくBluesky Socialと繋がりつつ、危険コンテンツも共有できる環境を目指す。

具体的には以下のような感じ。

• Bluesky Socialではtakedown対象になりうるような特定のコンテンツを、一部の人には見えるように発信する
  • 以降はこれを「危険コンテンツ」と呼ぶ
  • 一般的には画像(blob)が対象になることが多いが、ここではrecordとblob両方を検討する
  • 共有相手は自発的に設定等をやってくれるものとする
• 危険コンテンツを除いて、Bluesky Social上でもBluesky Social利用者と同様にアクセスできる
  • 相互にフォローしたりリプライしたりできて、どちらからもそれが見える
• なるべく低コストに抑える
  • PDS以外は基本的にBluesky Socialのインフラにフリーライドする

解決方法

やり方はいくつか考えられるが、ここでは独自仕様の改造PDSを用意し、同一PDSのアカウントとのみ危険コンテンツを共有することを考える。

危険コンテンツは普通のコンテンツと同様のrecordやblobとして扱うが、アップロードAPI(createRecord/uploadBlob)に独自のフラグパラメータを追加して、危険コンテンツだと示すことにしよう。
独自のクライアントを用意したくなければ、フラグの代わりに適当なglobal labelを決めてself labelとして表せば、一部のクライアントは使えるかもしれない。

外部(例えば公式relay)からデータ取得要求が来た場合、危険コンテンツのみマスクし、それ以外を渡す。ただし、危険コンテンツの存在そのものを無かったことにしてはいけない。
relayやappviewはMSTの署名を検証するため、下手に誤魔化すと整合しなくなってしまう。そのため、対外的には「PDSでtakedownされた」ということにして、存在はするが見せられないことにする。

PDSからappviewのAPI(例えばgetTimeline)が呼ばれた場合、普通のPDSと同様にappviewにプロキシする。上図だとクライアントはbsky.appに直接接続しているかのように見えるが、実際には認証の都合上、PDSが仲介している。つまり、PDSはAPIレスポンスに介在する余地がある。
appviewには危険コンテンツは届いていないため、元レスポンスに危険コンテンツは当然含まれない。しかし、クライアントに返す前にPDS内部で留めていた危険コンテンツを混ぜ込んで、あたかもappviewに届いていたかのような結果を返す。

PDSはかなり頑張る必要があるだろうが、like数や返信のスレッド化を省けばいくらか楽になるかもしれない。

PDSでappviewのレスポンスを弄るというのは非常識に感じるかもしれないが、atproto的には案外そうでもない。公式PDSでもやっていることである。具体的にはread-after-writeと呼ばれるbsky API用の機能で、直前のbsky投稿を覚えておいて、getTimeline等に混ぜ込むというもの。
本来、PDSに投稿recordを追加してからrelayにクローリングされてappviewのDBに入るまで多少のラグがあるが、投稿者からすれば投稿した後に叩いたAPIに投稿が反映されていないのは如何にも気持ち悪い。不自然に感じて不具合を疑うこともあるだろう。そこで、read-after-writeで見かけだけ繕おうというわけだ²。

課題

PDS内でのみ共有できるということは、PDS依存度が高いということだ。強い言い方をすれば、atprotoの長所であるアカウントポータビリティを殺す³ことになる。

また、PDSがAPIにフックしてして弄るため、PDSが知っているAPIにしか危険コンテンツは乗せられない。典型的には、bsky投稿はうまくハンドリングしてくれるが、whtwnd投稿に危険コンテンツを付けたら誰からも見えなくなる、というようなことが起きるだろう。

この辺りは段階的に強化していくこともできそうだが、ここで細部詰めても仕方ないのでこんなところで。
将来的にはnon-public contents辺りが全てをどうにかしてくれるかもしれない。

Footnotes

1. API利用者が少なければより安価とされるが、relayのような実験結果があるわけではない。試みている人はいるものの、結果が出るにはまだ時間がかかるだろう。 ↩

2. 余談だが、公式クライアントで更新マークが出ていたのに、更新しても何も変わらない場合がある。その原因として、read-after-writeされた投稿がちゃんとappviewから返ってくるようになり、更新と判定されたことが考えられる。 ↩

3. とはいっても引越しはできるし、同一機能を持つPDSなら危険コンテンツも持ち越せるので、完全に使えないわけではないが。 ↩