# atprotoがやったこと/やっていないこと 10月18日。experimentだったADXがlink:https://blueskyweb.xyz/blog/10-18-2022-the-at-protocol[「Authenticated Transfer Protocol」に名を変え正式発表して]早一年。特にBlueskySocialが活発に動き出してからのatprotoは色々と変わったことや分かったことがあったので、まとめてみる。 とはいっても「何ができるか」はきっと各所で解説されているので、「何ができていないか」「何をしなくなったか」にフォーカスして、一周年記念らしからぬネガティブな話をする。一年間の道程の概略はlink:https://blueskyweb.xyz/blog/9-12-2023-one-million[本人達がまとめている]ので、そちらを参照されたい。 解説というより覚書のようなものなので、ある程度プロトコルの中身を知ってる前提。ユーザ視点では「ベータ開始当初の目標は一部未達成で、まだちゃんとベータ」「link:https://atproto.com/blog/2023-protocol-roadmap[来年頭に連合開始予定]」くらいの認識で良いと思う。 ## やろうとしていたこと 現在のプライベートベータの中で実現するとアナウンスしていたことが幾つかあるので、それらの達成状況から見ていく。 ### 2023/03 ベータ開始当初 https://blueskyweb.xyz/blog/3-2-2023-bluesky-beta-app ベータ自体は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 ==== 結論だけ言えば、順に未実現・実現済・実現済、というところか。 #### Domain names as usernames & account portability 前半、カスタムハンドル周りは実現済み。ハンドル更新APIはこの時点で既にlink:https://github.com/bluesky-social/atproto/pull/547[実装済み]で、クライアント側もこのブログ記事の直後にlink:https://github.com/bluesky-social/social-app/pull/273[実装された]。ハンドル検証の仕組みはその後何度か更新されたが、基本的にはこの時点で達成されたと見ていいだろう。 一方でaccount portablilityについては、PDS引っ越し(account migration)を意味すると解釈するのであればまだ実現できたとは言えない。どちらにせよPDS連合が始まらないことにはあまり意味が無いが、それは置いておいてもまだ部分的な実装に止まっている。 まず、引っ越しに最低限必要なことは以下の通り。 * DIDドキュメントの書き換え * 指定したDIDでのアカウント作成 * repositoryの読み込み DIDドキュメントの書き換えは現在一部ユーザのみ可能。具体的にはアカウント登録時にrecovery keyを登録しているか、did:webを使っている場合のみfootnote:[どちらも公式クライアントでは対応していないため、アカウント作成時に直接APIを叩くかサードパーティクライアントが必要]。流石に救済策はあると思うが、今のところ明かされていない。 既存DIDを使ったアカウント作成APIは5月にlink:https://github.com/bluesky-social/atproto/pull/1011[実装された]が、クライアントは非対応。また、これでアカウント作成した時点では空のアカウントが作成され、データなどは一切引き継がれない。フォロワーは残っているが、投稿やフォローはリセットされた状態。 データは別途インポートする必要があり、このAPIは3月に一度link:https://github.com/bluesky-social/atproto/pull/736[プルリクエストにはなった]ものの、マージされることなく放置されている。link:https://github.com/bluesky-social/atproto/discussions/1711#:~:text=account%20migration%3A%20new%20protocol%20features%20to%20enable%20both%20%22happy%20path%22%20and%20antagonistic%2Ffallback%20migration%20of%20repos%20(and%20blobs%2C%20and%20identity)%20between%20pds%20instances[遠からず実装するつもりはある様子]。happy pathと呼んでいるのがlink:https://github.com/bluesky-social/atproto/discussions/1621#discussioncomment-7040798[PDS間で直接連携]、fallback migrationが旧PDSに頼らず移行する方法か？ #### Composable moderation & reputation systems composable moderationの概念はlink:https://blueskyweb.xyz/blog/4-13-2023-moderation[別記事で説明されている]が、簡単に言えばモデレーション主体が複数いて組み合わせられることを目指している。 link:https://github.com/bluesky-social/proposals/tree/main/0002-labeling-and-moderation-controls[proposal]も参照。 これは将来的にはまだまだ発展の余地があるものの、ある程度達成されたと見て良いだろう。 link:https://github.com/bluesky-social/atproto/pull/789[PDSによるラベリング]とlink:https://github.com/bluesky-social/atproto/pull/851[appview(labeler?)によるラベリング]は4月に実装され、link:https://github.com/bluesky-social/atproto/pull/1444[投稿者本人よるラベリング(self-labeling)]も8月に実装されているfootnote:[ただし、self-labelingはbsky lexiconの機能であるため、atprotoの機能と言えるかは少し怪しい。]。 今後はlink:https://github.com/bluesky-social/atproto/discussions/1711#:~:text=third-party%20labeling%3A%20protocol-level%20ability%20to%20distribute%20and%20subscribe%20to%20labels%20from%20many%20sources%2C%20including%20cryptographic%20signatures%20for%20verification[ユーザによるラベリングも実装予定]。 #### Algorithmic choice & custom feeds algorithmic choiceもlink:https://blueskyweb.xyz/blog/3-30-2023-algorithmic-choice[ブログ記事で説明されている]が、要するにカスタムフィードのことらしい。 もはやatprotoではなくbskyに特化した話ではあるが、5月にlink:https://github.com/bluesky-social/atproto/pull/1001[カスタムフィードが実装され]、8月にはlink:https://github.com/bluesky-social/atproto/pull/1542[おすすめフィード機能も実装された]ため、実現されたと考えていいだろう。 より一般に、同じAPIに対してアルゴリズムを選べる機構としてappview切り替えが考えられるが、これはlink:https://github.com/bluesky-social/atproto/discussions/1711#:~:text=client%20request%20proxy%20header%3A%20documented%20ability%20to%20control%20which%20appview%20instance%20requests%20will%20be%20proxied%20to%20from%20the%20pds%2C%20controlled%20using%20an%20http%20header[近々実装予定とのこと]。Blueskyのlink:https://blueskyweb.xyz/blog/6-13-2023-what-is-bluesky[federation思想の一端を担っている]機能と思われるため、実現が望まれる。 ### 2023/06 ロードマップ発表 https://blueskyweb.xyz/blog/6-02-2023-beta-update BlueskySocialのユーザ数が10万人突破した頃のブログ記事。なお、2023/10現在はlink:https://blueskyweb.xyz/blog/9-12-2023-one-million[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つは開発というより運用寄りの話になるが、実現されたと見てよいだろう。 #### Updated community guidelines for the app ちょっと見つけ難いが、6月にlink:https://blueskyweb.xyz/support[更新された規約]が発表された。規約の中身が不明瞭であるという意見も当時出ており、federation後に通じる規約かは怪しいが、とりあえず達成された？ #### Protocol documentation and specifications この頃まではatproto発表当時のプロトコル仕様から約半年間ほぼ更新されていなかったが、このブログ記事が出た頃から全面的に更新され、現在に至るまでメンテされるようになった。 同時期にlink:https://github.com/bluesky-social/atproto/discussions[atprotoレポジトリのdiscussion]も大幅に整理されている。footnote:[どちらも大半がlink:https://github.com/bnewbold[bnewworld]の手で行われており、担当として割り当てられたのかもしれない。感謝。] ## やるかもしれないこと 現時点では実現されていないけど、言及されたことがある機能とか。 個別のissueやdiscussionでの発言を見れば他にも色々出てくるが、ここではドキュメントでの言及に絞る。 直近で予定されている変更がlink:https://github.com/bluesky-social/atproto/discussions/1711[discussion]にまとめられているが、プロトコル的に目新しいトピックは無いので割愛。 ### 今後予定されていること 公式ドキュメントでも、現在不足している機能はlink:https://atproto.com/specs/atp#what-is-missing[「What Is Missing?」]とlink:https://atproto.com/specs/atp#future-work[「Future Work」]で示されている。他にもドキュメント各所で「Possible Future Changes」というのもあるが、これは細かい話が大半なので無視。 比較的最近更新されたものなので、実現はかなり期待できる。 #### Account Migration 前述のため省略 #### Repository Sync link:https://github.com/bluesky-social/atproto/pull/1479[repository構造が変わった]ことにも関連して、差分取得などの仕様を規格化する話。サーバ間通信で大事な話ではあるが、関係あるのがBGSくらい＆割と細かい話なので、そんなに気にしなくていいかもしれない。 #### Repository Event Stream appviewやfeed generatorがBGSから情報を取得する際に利用する、所謂firehoseについて。これも、実装されていないというよりは今の実装を説明するような仕様が必要という話。 #### Blob Export 実は、前述のPDS引越しではrepositoryの引っ越しのみしか話しておらず、blob(≒画像)は対象外になっている。取得用API等は存在するため最低限のサポートはしていると言えるが、細かい扱いについては未検討の模様。 個人的には、link:https://github.com/bluesky-social/atproto/blob/main/lexicons/app/bsky/actor/putPreferences.json[app.bsky.actor.putPreferences]で入れられる設定もPDS管理のため取り出せる必要があると思うが、同様に検討してほしいところfootnote:[bskyで規定されているデータがPDSに保存されるのが変なだけ、と言いたくもなるが。]。 #### Moderation Primitives おそらくcomposable moderationに関連してlabelerの説明なども含めて行うというような話だと思われる。 そもそもBGSだappviewだの話も仕様に出てきておらず、federation architectureの説明が先にあるべきなのではないかと思うのだが、その辺りの見通しは不明。 #### Lexicon Resolution 今のPDS実装はatprotoとbsky以外のlexiconの存在を認めず、知らない型のrecordは拒否するため、それらの対応をどうするかという話。基本的にはlexiconファイルの取得方法さえ決まればプロトコル的には実現できるはず。 似たような話で未知のqueryやprocedureのproxy先をlexiconで指定できるようにするべきという案もlink:https://atproto.com/specs/xrpc#possible-future-changes[挙がっている]が、まだ先は遠そう。 #### 3rd Party Authentication and Authorization よく話題に上るOAuthとかの話。link:https://github.com/bluesky-social/atproto/issues/1624#issuecomment-1724176713[現在検討中のようなので]比較的実現が近いかもしれない。 authentication(認証)は外部サービスへのログインにatprotoアカウントを使う話、authorization(認可)はatprotoクライアントに権限を与える話だと思えば良い。 link:https://github.com/bluesky-social/atproto/discussions/1711#:~:text=auth%20refactor%3A%20both%20third-party%20auth%20flows%20(eg%2C%20oauth2)%2C%20and%20to%20support%20verifiable%20inter-service%20requests%20(eg%2C%20with%20ucans)[別の説明]だと2種類の認証を検討中とのこと。 third-party auth flows (eg, OAuth2):: 何を以て「サードパーティ」と言っているか不明だが、おそらくapp passwordに代わってクライアント等にPDSへのアクセス権を与える仕組みと思われる。可能性としてはユーザの認証サーバを使う可能性もあるか？footnote:[両者の違いはこの記事が分かり易い。 https://aaronparecki.com/2023/03/09/5/bluesky-and-oauth] verifiable inter-service requests (eg, with UCANs):: 謎。今アクセストークンとして使っているJWTを強化しようとしている？サーバ間(PDS-appviewやappview-labeler)向けなのかもしれない。「link:https://github.com/bluesky-social/atproto/issues/947#issuecomment-1532271039[service-to-service auth]」と同義か。 #### Non-Public Content これも多くの人が待ち望んでいるらしいDMとか非公開アカウントとかの話。今ある仕組みとは大きく異なる形になるようで、実現はまだ遠いとも明言されている。 #### Protocol Governance and Formal Standards Process ActivityPubがW3Cで標準化されているように、仕様の管理手順を定めたり権威付けしたりする話。ある程度出来上がってからの話になると思われるので、これもまだ先は遠いか。 ### ADX時代にやろうとしていたこと atprotoがこの名前になる前、ADXという名前だった頃footnote:[余談だが、ADXという名前も開発を発表するタイミングでlink:https://github.com/bluesky-social/atproto/pull/96[決められており]、それ以前の内部では単にSKY protocolとか単にblueskyとか呼ばれていたらしい。]、色々な構想をまとめたlink:https://github.com/bluesky-social/atproto/blob/3c7b12e8de4f9e75675d847c7a9a45d5a0e44291/architecture.md[architecture.md]というファイルがあった。改名のタイミングでファイルは削除されており、棚上げにされたまま実現されていない機能があるため、それらを見ていく。 今とは色々な方針が変わっているため実現はあまり期待できないが、ものによっては将来復活するかもしれない。 #### コンソーシアム制DIDメソッド https://github.com/bluesky-social/atproto/blob/3c7b12e8de4f9e75675d847c7a9a45d5a0e44291/architecture.md#the-did-consortium did:plcの運用の話。今でも「将来的にはコンソーシアム作る」みたいな話はされているし、複数PLCサーバ間で同期するようにする&誰かが監査の任に就けば概ね達成されるようにも見えるが、未だ検討段階らしい。 どちらにせよ個別のDIDメソッドの内情はatprotoの話から少し離れるので、個人的にはあまり深掘りしたくはないところだが……。 #### 鍵管理システム https://github.com/bluesky-social/atproto/blob/3c7b12e8de4f9e75675d847c7a9a45d5a0e44291/architecture.md#the-did-consortium 現在ほとんどのユーザの秘密鍵(signing key, rotation key)はPDSが管理しているが、その一部をユーザの手元で管理するためのシステムの話。atprotoになってから話に上がらなくなったので、現状の動向は不明。 当時はUCANによりクライアント毎に異なる署名鍵を持つことが想定されていたため、そのための鍵生成なども期待されていた。用途は減ったものの、PDSが止まってしまってから引っ越す場合にはユーザがローカルに鍵を持っておく必要があるため、今後の展開に期待。 #### UCANによる権限管理 https://github.com/bluesky-social/atproto/blob/3c7b12e8de4f9e75675d847c7a9a45d5a0e44291/architecture.md#permissioning クライアント等の認証認可手段として、UCANfootnote:[UCANはJWTで公開鍵間の権限委譲を表すフォーマット。 https://ucan.xyz]で権限を委譲した署名鍵をそれぞれに持たせることが検討されていたが、その後取り下げられてlink:https://github.com/bluesky-social/atproto/pull/444[コードも削除されて]いる。 今はクライアントは署名鍵を持たず、API呼び出しのみ行うため、復活の見込みは無いfootnote:[クライアントによるrepository操作はcommit署名の検証でAPI認証]。今は異なる形でのUCAN活用が検討されているようだが、詳細は不明。 #### PDS間の直接通信 https://github.com/bluesky-social/atproto/blob/3c7b12e8de4f9e75675d847c7a9a45d5a0e44291/architecture.md#federated-networking atprotoではsmall-worldと呼ぶタイプの通信。ActivityPubを知ってる人はfederationと聞いて大体がこれを思い浮かべるが、実は実装されていない。 link:https://blueskyweb.xyz/blog/5-5-2023-federation-architecture[federation architecture発表時]に「big-world主体でいく」と宣言して以来、言及されることもほとんど無く、実装するつもりがあるかも不明。 #### repositoryの分散型バージョン管理 https://github.com/bluesky-social/atproto/blob/3c7b12e8de4f9e75675d847c7a9a45d5a0e44291/architecture.md#commits ADXの頃のクライアントはUCANで作ったクライアント固有の鍵でそれぞれcommitに署名し、それをPDSでマージすることが想定されており、git的な履歴管理をしていたfootnote:[ちなみに、現状のようにPDSに署名もしてもらうクライアントも当時存在しており、link:https://github.com/bluesky-social/atproto/blob/3c7b12e8de4f9e75675d847c7a9a45d5a0e44291/architecture.md#client-to-server[Light Client]と呼ばれていた。]。 今はPDS以外はrepository更新できず、link:https://github.com/bluesky-social/atproto/pull/1479[repository履歴も記録されなくなった]ため、おそらくもう復活することはない。