atprotoモデレーション概論 Bluesky編
ここまでは全て仕様の話だったが、最後に実装と運用の話。Bluesky Socialと公式実装に固有の事情について簡単に説明する。
bsky appviewとlabeler
公式appview実装では、全てのlabelをsubscribeLabelsで取得する。呼ぶタイミングは未確認。
取得したlabelはappviewで保持して、APIが呼ばれたらローカルで参照する仕組み。そのため、一度発行したlabelは、明示的にnegで取り下げない限り残り続ける。
mod service
公式PDS実装やappview実装は、mod serviceというものが設定できる。
これは管理者権限のうちモデレーション関連のみを委任されたサーバだと思えばいい。雑に言えば、外部からtakedownできるということ。また、PDSへの通報もmod serviceに転送されるようになる。
沢山存在する公式PDSのモデレーションを一元化した上で、モデレータチームに過剰な権限を与えないための機構という感じ。
mod serviceはlabelerを兼ねることが多く、認証用の鍵はlabelerの場合と同じもの(service ID #atproto_labeler)を使うことになっている。
Ozone
公式PDS/appviewが使っているmod serviceの実装はOzoneという名前で公開されている1。labelerアカウントは@moderation.bsky.app。
これは公式appciew+公式PDS全てのモデレーションを一括管理しているため、公式PDS(bsky.social)を使っている場合、bsky appviewでのtakedown≒PDSでのtakedownとなる。基本的には通報(公式クライアントにおける「投稿を報告」というやつ)を受けて、モデレータが判断する仕組み。
OzoneもXRPCで操作できるようになっており、tools.ozoneという独自lexiconを持つ。また、基本的にはbskyコンテンツを対象としているため、モデレーション対象確認のためにgetPostThread等のbsky APIも備えている。
moderation.bsky.appはlabelerとしても強い権限を持っており、公式SDK(@atproto/apiパッケージ)を使うと、自動的にatproto-accept-labelers指定に追加される。しかもredact付き。つまり公式appview以外でも、少なくとも公式クライアントを使う限りはlabel(特に!takedown)が反映される。
モデレーションアカウントの設定画面を見れば分かるように、基本的なlabel2は大体ここで付けられている。
自動モデレーション
atprotoにlabelerの仕組みが導入される以前から動いている仕組みとして、automod(もしくはhepa)と呼ばれる機構が存在する。これは、NGワード検出や、Hive AIによる画像判定を使って、自動的にモデレーション対象を検出するもの。
検出したものは、報告としてOzoneに送られる模様。人手を挟まず自動承認している気がするが、詳細は追ってない。
一時期話題になったslur handleもautomodの範疇のはず。一方で有名企業のなりすまし等を防ぐreserved handleはPDS単位で管理している。
地域別labeler
公式クライアントでは、地域によって追加のlabelerを指定する場合がある。国毎の法令に応じて閲覧制限を行ったり、言語別の問題に対処するためではないかと思われるが、詳細未確認。
実際のlabelerを覗いてみると、labelは一切宣言しておらず、!takedownのみの運用ではないかと思われる。
その他のlabeler
有志labelerまとめが幾つかあるのでそちらを参照。例えば以下。
https://www.bluesky-labelers.io/
実装はOzoneベースのものの他、labeler作成キットskywareなどもある。Bluesky Labeler Starter Kitから使うと便利そう。
トレンドとして、自己申告型のlabelerが数多く出ている。モデレーションというよりはタグに近い用途で、モデレーションコストがかからない分ハードルも低いのだろう。
レート制限
少しだけlabeler以外も見ると、スパム対策として、公式PDSやrelayはレート制限が設けられている。詳細は以下参照。
https://docs.bsky.app/docs/advanced-guides/rate-limits
