昨今TwitterのCEOが変わり経営の仕方や機能に急激な変化が起こっています。収益に貢献しないと見られた機能が切られ、フォローしていないユーザーのツイートが流れるタイムラインを強制的に表示したりなどユーザー視点ではありがたくない仕様変更が多く見られるようになりました。こういう現象はSNSが中央集権的に運営されているから起こるんだ、ということで分散型のSNSが注目されているそうです1。分散型SNSとしてはMastodonがよく知られています。
分散型SNSを調べているとよく出てくる概念として、Fediverseというものがあります。FediverseはSNSを提供するサーバ同士がコンテンツ情報を融通（連合）し合っている状況のことです。Fediverseが実現されればあるサーバのユーザは別サーバのSNSのユーザの投稿をいいねしたりできます。Fediverseを実現するためには、サーバ同士がやり取りするための規格・プロトコルが必要となりますが、その代表例がActivityPubです2。なお、ActivityPubはサーバ同士の連合だけでなくサーバクライアント間の通信も規定します。MastodonはActivityPubを実装しています。
AT Protocolは分散型SNSを実現するプロトコルの一つです。Twitterの創業者であるJack Dorsey氏が作ろうとしている分散型SNS、Blueskyで使用される予定です。ActivityPubに対してAT Protocolでは
- Portability
ActivityPubではサーバが消えるとそこにひもづいたアイデンティティが一緒に消えるのに対し、AT Protocolではアイデンティティは特定サービスによって発行されるものではないので、サーバ・サービスの終了とは関係なく存続できる - Scale
グローバルなスケールでのネットワークに参加できる。ActivityPubでは結びつきの強い人たちとやり取りできる(small world)が、例えばトレンドになっているハッシュタグが何で、どの投稿が全世界でどれくらいいいねされていて、といったグローバルなネットワークに参加している体験を得ることができない。 - Trust
スパムや偏見などの信頼性を損ねるような問題に対し、透明性があり検証可能なシステムを作ることで対処する
ことを目指しているそうです。
Jack DorseyがTwitterの競合みたいなものをガチで作っているというのが面白そうなのでAT Protocolに関して最近色々調べました。調べる中で個人的に疑問に思った点とその自分なりの答えを以下に書く予定です。なお、以下に挙げる文献を先に読むことをおすすめします。
- AT Protocol (BlueSky)仕様を読んでみた ～ W3C DID仕様を添えて ～ – Qiita
- Protocol Overview | AT Protocol
- bluesky-social/indigo: Go source code for Bluesky's atproto services. NOT STABLE (yet)
プロトコルページに書かれていない部分は今の実装を見る他なさそう
PDS
PDSとは投稿などのデータを置いてあり、様々なSNS機能を実装したサーバ（Personal Data Storage）のことです。PDSとの会話はXRPCというプロトコルで行います。XRPCはHTTP GETとPOSTのみを使います。XRPCを使って行う操作のことをMethodと言います3。Methodは「com.atproto.identity.resolveHandle」のような形式の名前が与えられています。各Methodの仕様を記述するドキュメント形式はLexiconと呼ばれ、どのような入力を取り、出力を出すのか、どういうエラーが出るのかが書かれています。PDS同士はXRPCで会話し、連合します。
Decentralized Identifiers (DID)
Decentralized Identifiers (DID) は何かしらの存在（DID Subject）に与える事のできるIDのことです。UUIDなどと違うのは、IDはDID Documentに何らかの方法で解決する（resolve）ことができます。DID DocumentはDID Subjectに関して何かしらの情報を記述するどこかに保存されたドキュメントです。DIDの解決に当たっては中央集権的な機関などが必要であってはなりません。DID DocumentをCRUDできるのはその権限を持った者（DID Controller）だけです。DID Controllerではない、DID Documentの保存先の関係者などが勝手に変更できてはなりません。DID ControllerとDID Subjectは同一である事もあれば、別の存在であることもあります。図にすると以下のようになります。
(DID-CORE Figure2より)
…などW3CのDID-COREドキュメントに書かれているのですが、抽象的でよくわかりませんよね。黄線を引いたように何らかのとか、任意のとかが多すぎて全くイメージがつきません。なぜこうなっているかというと、DIDの仕様自体はDID methodが共通で実装すべき構成を記述しているに過ぎないからです。DID methodとは、「何にDIDを与えるのか」「どのようにDID（のdid method-specific identifier部）を作るのか」「どうやってDIDを解決するのか」「DID Documentに標準項目以外何を書くのか」「どうやってDID Documentを保存するのか」「DID Documentをどうやって変更するのか」などを具体的に決めるものです。DID methodは、DIDの表記「did:○○：○○」における真ん中の部分で指定されます。
DID methodの具体例として、AT Protocolで用いられるdid:key、did:web、did:plcに関して見ていきます。
did:key
did:keyは公開鍵をDID SubjectとするDID methodです。did:keyではDID DocumentはDIDから導出できます。そのため、Verifiable Data Registryは存在しません。did:keyのmethod-specific identifier部は公開鍵の種類と公開鍵データに対して、multibase base58-btc変換とmulticodec変換を施すことで得られます。DID Documentの導出方法に関してはこちらに載っています。日本語解説はQiitaにもあります。did:keyで作成されるDIDの例は、
did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK
のような感じです。
did:keyではDID Subjectは公開鍵を作った人になりそうです。また、同じDIDに対してDID Documentは一意に定まるので、更新や削除はできません。
did:web
did:webはFQDNをDID SubjectとするDID methodです。Method-specific identifier部はそのままホスト名を入れます。具体的には、
did:web:w3c-ccg.github.io
のような感じです。
did:webにおいて、DIDの解決はそのホストにアクセスしてHTTPでDID DocumentをGETすることで行われます。FQDNの名前解決はもちろんDNSを使用します。DID Documentはmethod-specific identifier部にパスが指定されなければ、/.well-known/did.jsonに設置されていると仮定されます。先程の具体例で言えば、https://w3c-ccg.github.io/.well-known/did.jsonがDID DocumentのURLです。
DID ControllerはそのFQDNを所有していて、そのFQDN下で動くサーバ上のdid.jsonを編集できる人になります。FQDNを放棄すると他人が同じ名前を取得してDID Documentをいじる権限を得ることになります。また、DIDの解決にDNSを使っており、DNSに関わるリゾルバやコンテンツサーバは信頼できるものとしています4。
did:plc (2023/06/04現在)
did:plcはAT Protocolにおいて、ユーザーアカウントをDID SubjectとするDID methodです。このmethodを理解するためには、前提となるサーバ構成とデータ構造に関して理解する必要があります。
did:plcではVerifiable StorageとしてPLCサーバというものが登場します。このPLCサーバ上にはユーザーの鍵とPDSの場所に関する情報を保持する”Operations”というデータ構造が置かれています。DID DocumentはOperationsから導出されます。DIDの解決の際にはPLCサーバに問い合わせることになります。
ユーザーは自分の存在を作り出す際にまずrotationKeyとsigningKeyの鍵ペアを手元で作成します。rotationKeyはOperationに署名するための鍵で、signingKeyはPDS内のデータリポジトリに対して変更を加えるための鍵です。次に、Operation（Genesis operation）を作成してPLCサーバにPOSTします。最初のOperationなのでprevフィールドはnullとします。このGenesis operationデータからハッシュ値を計算することで、ユーザーのmethod-specific identifierが決定されます。
鍵情報やPDS情報を変更したい場合は新規OperationをPLCサーバにPOSTします。このOperationには前回Operationのハッシュ値が記載されています。PLCサーバは新たに到達したOperationをアペンドする先をこのハッシュ値で識別するはずです。また、各Operationには署名が付与されています。署名の検証に失敗（＝秘密鍵を持たない者の要求）するとOperationはPDSに拒絶されます。署名の検証は、アペンド先の最新のOperationに記載されているrotationKeysを用いて行われます。
rotationKeysは配列であり、5個まで鍵を登録できます。鍵には優先順位があり、配列の一番最初に記載された鍵が最も優先順位の高い鍵です。低い優先順位の鍵で署名されたOperationは、72時間以内ならより高い優先順位の鍵で署名されたOperationを作ることで無効化できます。例えば、AというOperationからBというOperationを、優先順位1の鍵で生やしたとします。Bを生やしてから72時間以内に優先順位2の鍵でAからCというOperationを生やせば、Bは無効化できます。この仕組みはアカウントの復旧で使われます。
このように、did:plcではPLCサーバが中央集権チックに振る舞っており、色々悪さできそうに見えます。しかし、PLCサーバは秘密鍵を持っていないので、勝手なOperationを追加したりはできません。Operationの履歴のうち新しいものを勝手に消したり、アカウント復旧でOperationが分岐したとき、間違ったほうをあえて返すなどの悪さはできます。
参考：DID Placeholder (did:plc)レビュー
ハンドル
did:plcのDIDはハッシュ値を使っているため、did:plc:yk4dd2qkboz2yv6tpubpc6coのように可読性が低いです。そのため、可読性の高い名前であるハンドルがAT Protocolではサポートされています。ハンドルはドメイン名です。例えばalice.pds.comのようなものです。ハンドルはDIDに解決されなければなりません。そのためにはまずDNSでハンドルのIPアドレスを問い合わせます。このIPアドレス上で動いているサーバはハンドルを持っているユーザが今使っているPDSです。次にそのPDSの/xrpc/com.atproto.identity.resolveHandleに対してGETリクエストを投げます。すると、PDSはDIDを返します。
- ありがたくない仕様変更は運営側が収益を確保しようとする試みの結果として生じる現象なので、そういう仕様変更が不可能なSNSがどうやって維持されていくのか楽しみです
- むしろActivityPub限定の概念として使う人が多い？ニコニコ大百科は違うと言っているが
- DID Methodといい、なんとかMethodが多すぎる…
- 各階層のネームサーバを提供している団体は複数なので中央集権的じゃないと言える…？
コメント