Blueskyなどの分散SNSにみんなも来ようよ、楽しいよ、という話

categories:
- 📝覚え書き
tags:
- 🏷️ハウツー
- 🏷️ソーシャルメディア
topics:
- Misskeyなどの分散SNSにみんなも来ようよ、楽しいよ、という話

以前の話

パンクな試みが好きだ。考えを聞くのが好きだ。なにより、実現していない絵空事や青写真を見て想像をめぐらすのが大好きだ。

X（旧 Twitter）が色々アレないま分散 SNS はこれらの条件をすべて満たすフロンティアとなっており、ロマンあふれる楽しい世界が広がっている。みんなも来ようよ、楽しいよと、この記事は言いたい。

X の凍結ハードルが下がったいま追い出された時の保険として知識を持っていてもいいだろう、と付け加えておく。

前回は Fediverse について取り上げた。今回は Bluesky こと ATProtocol について話していく。正直なところ Fediverse のほうが代表的な存在なので、「分散 SNS ってなに！？」という方はまず前回の記事『Misskey などの分散 SNS にみんなも来ようよ、楽しいよ、という話』を読んでほしい。

ついでに言えば、筆者はにわかだ。自信があまりないので間違っているところがあったらこっそり優しく教えてほしい。まじめに知りたくなったら、参考資料の欄から原典を当たってほしい。この記事は、あくまでふんわり雰囲気が分かる所までを目指していく。

Bluesky の表面をなぞる

まずは表面だけ軽くなぞってみよう。

Bluesky は Twitter 創始者ジャック・ドーシーらが発案した分散型 SNS プロジェクトだ。もともと Twitter の社内プロジェクトだった。分社、独立し現在の形になる。

ユーザー登録するにはいまのところ招待コードが必要だ。もし友達が持っていたら君は運がいい。友達がいなかったら？うん。

招待コードが必要なのには訳がある。というのも、このサービスはまだいろいろ実験中なのだ。参加者はベータテスターのようなものだと考えたほうが良い。破壊的変更もバンバン起こるぞ！

分散型 SNS というからには、中央集権的なサーバーが存在しないのが特徴だ。複数のサーバーが協調しあって一つのサービスを実現する。

そして、これらは ATProtocol という技術によって可能となる。

ATProtocol の目指す姿

ATProtocol とは Authenticated Transfer Protocol の略、平たく言えば非中央集権型アプリケーションにおける情報の保管と通信を担うプロトコル――なんて言っても何が何やらという感じだろう。

まず構想から話していこう。大体三つの構想がある。

フェデレーションソーシャル
アルゴリズムによる選択
アカウントポータビリティ

フェデレーションソーシャル

Bluesky と同じように ATProtocol を採用しているサービスとなら、誰とでもつながれる。例えばサービス A に君がいたとして、普通はサービス B にいる友達とはつながれない。しかし、ATProtocol がサービス間に共有されていれば繋がれる。Fediverse と違うのは、連合はシステム内部で行われ、君はそのことをあまり意識しないで済むということだ。そして、サービス A に不満があれば、サービス B に移動することだってできる。

アルゴリズムによる選択

X のおすすめ欄でおなじみだろう、レコメンドアルゴリズムというものがある。ATProtocol ではこれを自由に作って公開し、誰かが公開したものを自由に手に入れることができる。これをアルゴリズムのオープンマーケットと呼んでいる。

アカウントポータビリティ

写真、書き込み、自分の ID など、様々なものを君はサービスに預ける。サービスが消えればそれまでだ。しかし、ATProtocol ではそれらを失うことなく「ホストの乗り換え」ができる。

ATProtocol の連合モデルをなぞる

ここからは技術的内容が含まれるので、興味がない人は読まなくても構わない。ATProtocol を構成する仲間たちを見ていこう。

まずは連合の仕組みからだ。

Personal Data Server（PDS）

君のクライアントは通常、君が所属する PDS と通信して全てのことを行う。そう、PDS は君の代理人なのだ。君の投稿データなどが含まれるリポジトリやその署名鍵をホストする。PDS はいくつもある想定だ。君が所属している PDS の運営者が嫌な奴だったら、引っ越すことができるのだ。

Big Graph Service（BGS）

いくつもある PDS を BGS がつなげる。いうなれば BGS は「大きな世界」のネットワークを処理するのだ。PDS をクロールしてデータを収集し、他のサービスが使用できるように、一つの大きなストリームに出力する。

App View

アプリに表示されるものすべてがここで組み立てられる。BGS からデータを取り込んで様々な形に「加工」したり、統計処理を行ったりする。君が Bluesky で見るいいねの数字はここで生まれるのだ。

連合の「大きな世界」設計は Web を参考にしたらしい。Bluesky チームは Web こそが最も成功した分散システムだと思っているのだ。

ATProtocol の ID をなぞる

ATProtocol で使われる ID についてなぞっていこう。なんで ID なんかに文を一章も設けるのかって？これが重要なんだ、そして複雑。全くもう。

Handle

みんな知ってるね。ログインするときに使うアレだ。ユーザ名。友達とつながりたいときはこの Handle を教えればいい。

形式は alice.host.com のようになっている。後半にドメインが書いてあり、DNS 名であることもわかるだろう。

名前部分は気に入らなかったら変更もできる、ユーザ向けの識別子だ。そう、「ユーザ向けの」。

分散型識別子（DID）

ユーザ向けの識別子である Handle に対して、こちらはシステム向けの識別子だ。一度発行したら変更はできない。君を、君がアカウントを持ち続ける限り永遠に示し続ける識別子だ。これは君だ。

ドメイン名が IP アドレスに解決されるように、Handle は DID に解決される。これは PDS が担う。

まず DID が何者かについて話しておかなければならないだろう。DID は W3C 標準の仕様だ。自己主権型・分散型の識別子 (Identifier) と呼ばれている。個人が自分の ID を自分自身で管理する、ということができる。ビッグテックに全部おまかせ、はしない。イーロン的な奴に「お前は出禁やから ID 消すで」みたいなこともされない。

DID は DID Document に解決される。DID Document と言うのはホスティングサービスや、ユーザーの署名を検証するための公開鍵、その他 DID に紐づく様々な情報を格納するドキュメントだ。解決する方法のことを DID メソッドと言う。

ATProtocol では DID メソッドを二通り使うことができる。did-Web と DID Placeholder だ。

DID の解決

DID Placeholder では plc.directory というものに問い合わせる。

plc.directory は DNS サーバーに相当する。これのおかげで、君が所属する PDS が知らない、未知の PDS 所属のユーザーの情報にもアクセスできる。Placeholder という名の通り、この仕様は後になって変更されるかもしれない。

did-web の場合は DID にドメインが書いてあるので、そこに問い合わせる。

これらのおかげで、検証したりアクセスしたりできる。

回復鍵の存在

ここで一つ重要なことを付け加えておく。PDS は君の代理人だ。君の代わりに署名鍵を使用して DID Document に署名する。しかし、PDS だって裏切るかもしれないし、誰かが不正アクセスをして署名鍵を盗み出すかもしれない。そこで「回復鍵」が用意されている。悪意のあるものに対する安全策だ。回復鍵は PDS が所有するどんな鍵よりも大きな権限を持つのだ。これで強制的に PDS を「引っ越し」できる。これは君自身で管理する必要がある。

むすび

はたして記事を書き終わることができた。技術解説が多くなった印象がある。特に DID 周りは私にとっても難しく、「なんだこれは！」の連続だった。でも、解説記事を書いたおかげで少しだけ理解できた気がする。これは良かった。私が個人的にやっている集会でも、近いうちにスライドをまとめて発表したいと思う。分かりやすいかと思って、時々「君」という表現をしたことをお詫びする。君よ、私の記事をここまで読んでくれてありがとう。理解の一助になれば幸いだ。