10月18日。experimentだったADXが「Authenticated Transfer Protocol」に名を変え正式発表して早一年。特にBlueskySocialが活発に動き出してからのatprotoは色々と変わったことや分かったことがあったので、まとめてみる。
とはいっても「何ができるか」はきっと各所で解説されているので、「何ができていないか」「何をしなくなったか」にフォーカスして、一周年記念らしからぬネガティブな話をする。一年間の道程の概略は本人達がまとめているので、そちらを参照されたい。
解説というより覚書のようなものなので、ある程度プロトコルの中身を知ってる前提。ユーザ視点では「ベータ開始当初の目標は一部未達成で、まだちゃんとベータ」「来年頭に連合開始予定」くらいの認識で良いと思う。
現在のプライベートベータの中で実現するとアナウンスしていたことが幾つかあるので、それらの達成状況から見ていく。
ベータ自体は1月から始めてるそうだが、やってることを初めて公言したブログ記事がこれで、ベータの間にやることとして以下のように書いている。
Our focus right now is on finishing atproto and surfacing its novel features in the app. Here’s what you can expect to see in the next few months:
-
Domain names as usernames & account portability
-
Composable moderation & reputation systems
-
Algorithmic choice & custom feeds
結論だけ言えば、順に未実現・実現済・実現済、というところか。
前半、カスタムハンドル周りは実現済み。ハンドル更新APIはこの時点で既に実装済みで、クライアント側もこのブログ記事の直後に実装された。ハンドル検証の仕組みはその後何度か更新されたが、基本的にはこの時点で達成されたと見ていいだろう。
一方でaccount portablilityについては、PDS引っ越し(account migration)を意味すると解釈するのであればまだ実現できたとは言えない。どちらにせよPDS連合が始まらないことにはあまり意味が無いが、それは置いておいてもまだ部分的な実装に止まっている。
まず、引っ越しに最低限必要なことは以下の通り。
-
DIDドキュメントの書き換え
-
指定したDIDでのアカウント作成
-
repositoryの読み込み
DIDドキュメントの書き換えは現在一部ユーザのみ可能。具体的にはアカウント登録時にrecovery keyを登録しているか、did:webを使っている場合のみ[1]。流石に救済策はあると思うが、今のところ明かされていない。
既存DIDを使ったアカウント作成APIは5月に実装されたが、クライアントは非対応。また、これでアカウント作成した時点では空のアカウントが作成され、データなどは一切引き継がれない。フォロワーは残っているが、投稿やフォローはリセットされた状態。
データは別途インポートする必要があり、このAPIは3月に一度プルリクエストにはなったものの、マージされることなく放置されている。遠からず実装するつもりはある様子。happy pathと呼んでいるのがPDS間で直接連携、fallback migrationが旧PDSに頼らず移行する方法か？
composable moderationの概念は別記事で説明されているが、簡単に言えばモデレーション主体が複数いて組み合わせられることを目指している。 proposalも参照。
これは将来的にはまだまだ発展の余地があるものの、ある程度達成されたと見て良いだろう。
PDSによるラベリングとappview(labeler?)によるラベリングは4月に実装され、投稿者本人よるラベリング(self-labeling)も8月に実装されている[2]。
今後はユーザによるラベリングも実装予定。
algorithmic choiceもブログ記事で説明されているが、要するにカスタムフィードのことらしい。
もはやatprotoではなくbskyに特化した話ではあるが、5月にカスタムフィードが実装され、8月にはおすすめフィード機能も実装されたため、実現されたと考えていいだろう。
より一般に、同じAPIに対してアルゴリズムを選べる機構としてappview切り替えが考えられるが、これは近々実装予定とのこと。Blueskyのfederation思想の一端を担っている機能と思われるため、実現が望まれる。
BlueskySocialのユーザ数が10万人突破した頃のブログ記事。なお、2023/10現在は10万人を超えている。
ロードマップとして以下のように述べている。
We recently shared our technical architecture for federation and are releasing a sandbox environment for developers to test soon.
Thanks to all who have used the feedback form within the app; we’ve heard your product feedback over the last few months. In the near future, you can expect these features and improvements as we move towards federation:
-
Improved labeling, reporting, and related moderation tooling
-
Account portability between servers
-
Updated community guidelines for the app
-
Protocol documentation and specifications
前2つは3月と同じトピックなので省略。後ろ2つは開発というより運用寄りの話になるが、実現されたと見てよいだろう。
ちょっと見つけ難いが、6月に更新された規約が発表された。規約の中身が不明瞭であるという意見も当時出ており、federation後に通じる規約かは怪しいが、とりあえず達成された？
この頃まではatproto発表当時のプロトコル仕様から約半年間ほぼ更新されていなかったが、このブログ記事が出た頃から全面的に更新され、現在に至るまでメンテされるようになった。
同時期にatprotoレポジトリのdiscussionも大幅に整理されている。[3]
現時点では実現されていないけど、言及されたことがある機能とか。
個別のissueやdiscussionでの発言を見れば他にも色々出てくるが、ここではドキュメントでの言及に絞る。 直近で予定されている変更がdiscussionにまとめられているが、プロトコル的に目新しいトピックは無いので割愛。
公式ドキュメントでも、現在不足している機能は「What Is Missing?」と「Future Work」で示されている。他にもドキュメント各所で「Possible Future Changes」というのもあるが、これは細かい話が大半なので無視。
比較的最近更新されたものなので、実現はかなり期待できる。
repository構造が変わったことにも関連して、差分取得などの仕様を規格化する話。サーバ間通信で大事な話ではあるが、関係あるのがBGSくらい＆割と細かい話なので、そんなに気にしなくていいかもしれない。
appviewやfeed generatorがBGSから情報を取得する際に利用する、所謂firehoseについて。これも、実装されていないというよりは今の実装を説明するような仕様が必要という話。
実は、前述のPDS引越しではrepositoryの引っ越しのみしか話しておらず、blob(≒画像)は対象外になっている。取得用API等は存在するため最低限のサポートはしていると言えるが、細かい扱いについては未検討の模様。
個人的には、app.bsky.actor.putPreferencesで入れられる設定もPDS管理のため取り出せる必要があると思うが、同様に検討してほしいところ[4]。
おそらくcomposable moderationに関連してlabelerの説明なども含めて行うというような話だと思われる。
そもそもBGSだappviewだの話も仕様に出てきておらず、federation architectureの説明が先にあるべきなのではないかと思うのだが、その辺りの見通しは不明。
今のPDS実装はatprotoとbsky以外のlexiconの存在を認めず、知らない型のrecordは拒否するため、それらの対応をどうするかという話。基本的にはlexiconファイルの取得方法さえ決まればプロトコル的には実現できるはず。
似たような話で未知のqueryやprocedureのproxy先をlexiconで指定できるようにするべきという案も挙がっているが、まだ先は遠そう。
よく話題に上るOAuthとかの話。現在検討中のようなので比較的実現が近いかもしれない。
authentication(認証)は外部サービスへのログインにatprotoアカウントを使う話、authorization(認可)はatprotoクライアントに権限を与える話だと思えば良い。
別の説明だと2種類の認証を検討中とのこと。
- third-party auth flows (eg, OAuth2)
-
何を以て「サードパーティ」と言っているか不明だが、おそらくapp passwordに代わってクライアント等にPDSへのアクセス権を与える仕組みと思われる。可能性としてはユーザの認証サーバを使う可能性もあるか？[5]
- verifiable inter-service requests (eg, with UCANs)
-
謎。今アクセストークンとして使っているJWTを強化しようとしている？サーバ間(PDS-appviewやappview-labeler)向けなのかもしれない。「service-to-service auth」と同義か。
atprotoがこの名前になる前、ADXという名前だった頃[6]、色々な構想をまとめたarchitecture.mdというファイルがあった。改名のタイミングでファイルは削除されており、棚上げにされたまま実現されていない機能があるため、それらを見ていく。
今とは色々な方針が変わっているため実現はあまり期待できないが、ものによっては将来復活するかもしれない。
did:plcの運用の話。今でも「将来的にはコンソーシアム作る」みたいな話はされているし、複数PLCサーバ間で同期するようにする&誰かが監査の任に就けば概ね達成されるようにも見えるが、未だ検討段階らしい。
どちらにせよ個別のDIDメソッドの内情はatprotoの話から少し離れるので、個人的にはあまり深掘りしたくはないところだが……。
現在ほとんどのユーザの秘密鍵(signing key, rotation key)はPDSが管理しているが、その一部をユーザの手元で管理するためのシステムの話。atprotoになってから話に上がらなくなったので、現状の動向は不明。
当時はUCANによりクライアント毎に異なる署名鍵を持つことが想定されていたため、そのための鍵生成なども期待されていた。用途は減ったものの、PDSが止まってしまってから引っ越す場合にはユーザがローカルに鍵を持っておく必要があるため、今後の展開に期待。
今はクライアントは署名鍵を持たず、API呼び出しのみ行うため、復活の見込みは無い[8]。今は異なる形でのUCAN活用が検討されているようだが、詳細は不明。
atprotoではsmall-worldと呼ぶタイプの通信。ActivityPubを知ってる人はfederationと聞いて大体がこれを思い浮かべるが、実は実装されていない。
federation architecture発表時に「big-world主体でいく」と宣言して以来、言及されることもほとんど無く、実装するつもりがあるかも不明。
ADXの頃のクライアントはUCANで作ったクライアント固有の鍵でそれぞれcommitに署名し、それをPDSでマージすることが想定されており、git的な履歴管理をしていた[9]。
今はPDS以外はrepository更新できず、repository履歴も記録されなくなったため、おそらくもう復活することはない。