Graber のドヤ顔インタビュー記事の翻訳が流れてきたので思い出した。
https://wired.jp/article/sz-vol57-jay-graber-the-big-interview/
Bluesky の集権性を指摘するブログ記事が出たのが2024年11月。
https://dustycloud.org/blog/how-decentralized-is-bluesky/
それから現在までで ATProto に本質的な変化があったかというとそんなことはない。初期設計に規定された部分が大きく、後から変えられる余地も限られている。
興味の中心は、Bluesky という組織が敵対的になったときに利用者に何ができて何ができないか。デフォルト設定のままの場合と利用者が注意深く事前準備する場合にわけて、いろんなシナリオを検討してみた。
結局のところデフォルト設定だと Bluesky がやりたい放題できて利用者がほとんど抵抗できない。
一方で、注意深く事前準備するとアカウントとデータを防衛できる範囲は小さくない。しかし、Bluesky でそこまで頑張るのであれば、とっつきにくさに目をつぶって Nostr を選ぶほうがトータルコストが低そう。
ATProto では (ActivityPub と同様に) 利用者 (のデータ) はいずれかのサーバにホストされることになり、そこが検閲の急所になる。ホストの中核が PDS (Personal Data Server)。もし Bluesky が PDS レベルでアカウントを停止させた場合、事前対策をとっていない普通の利用者にはほぼ何もできない。
Bluesky 開発者は2025年9月のブログ記事でアカウント停止を PDS ではなくアプリレベルで行うように改めると言っている。
https://pfrazee.leaflet.pub/3lz4sgu7iec2k
このような運用上の方針は外部からの検証が難しい。最終的にどこまで信用するかという非技術的な要素が残る。
それに、legal/network-abuse の理由では引き続き PDS レベルで停止させると述べている。この legal が曲者。例えばブラジルの裁判所があなたのアカウントを PDS レベルで停止させろと言ってくるというのは現実的なリスク。
では、利用者が注意深く事前準備をすると何ができるのか。
PDS が急所になることは ATProto 開発者にも当然認識されており、対策として PDS 間の移行を可能にするようにプロトコルが設計されている。ID だけでなく、データも CAR ファイルとして export/import できる。仕様にとどまらず、少なくとも API と参照実装は整備されている。開発者は真面目に仕事をしている。
ただし、これらの機能に対応する Bluesky の web UI は提供されていない (現状では CAR ファイルの export だけ)。普通の利用者がほとんど抵抗できないといったのはこれが理由。
Bluesky は開発者が元々やりたかったことと利用者が求めることの乖離が激しいようで、開発者のモチベーション維持が難しそう。
話が脱線したが、現状でこの種の機能を使おうとすると、基本は開発者向けの手段、CLI ツール (goat) などに頼ることになる。
https://github.com/bluesky-social/goat
具体的には、アカウントの rotationKeys に 自分が管理する公開鍵を登録し、Bluesky 側が保持している鍵よりも 優先順位を高くしておく (ここまでは自分で検証済み)。
https://whtwnd.com/bnewbold.net/3lj7jmt2ct72r
こうしておくと、仮に Bluesky が敵対的になって余計な変更をしたとしても、72時間以内であれば自分の鍵でその変更を差し戻せる仕様 (未検証)。
ただし、攻撃者に最上位の鍵の秘密鍵を盗まれたらアカウントを掌握されてしまい、利用者としてはお手上げ状態になる。こうなると Nostr でアカウントの秘密鍵が漏洩した場合と変わらない。
