ADXが見た夢（ATPのUCANの話）

Bluesky/ATProtocol 勉強会#0

https://www.youtube.com/watch?v=OjP0VkjRsC4&t=3052s

1. ADXが見た夢 ATPのUCANの話 2023.3.17 Bluesky/ATProtocol 勉強会#0
2. 自己紹介 Bluesky発足当時からたまに追ってた Matrixには入ってないのでブログやGitLab/GitHub追う程度 Bluesky Socialエアプ webや暗号は専門外
3. おことわり 規格概要は分かっている想定 規格の技術的な話だが、古い仕様の話なので実用的ではない 未来に復活する可能性も無くはない 疑問・ツッコミ・野次賛辞歓迎 資料公開時(or時間余ったら)ピックアップして補足予定
4. 2022.10.18 ATP誕生
5. ADX? Authenticated Data eXperiment ATPの前身……というか開発段階の名前 当時のリポジトリでは色々夢を語っていたが、改名と共に削除 architecture.md 今見てみると方針変更もいくつかある
6. 変わったもの UCANや鍵管理システムの主張が控えめに 仕様と実装に残りはしたが活用はされず DIDコンソーシアム→did:plcへ規模縮小 Lexiconによる機能拡張性
7. UCAN? 公開鍵間の推移的な権限委任を実現する仕様 https://ucan.xyz/ DID用OAuth 両者の公開鍵をJWTにまとめて署名 NostrのNIP-26と大体同じ原理
8. UCANサンプル（抜粋） { "iss": "did:key:z6Mkr5aefin1DzjG7MBJ3nsFCsnvHKEvTb...", "aud": "did:key:z6MkfQhLHBSFMuR7bQXTQeqe5kYUW51Hpf...", "nbf": 1529496683, "exp": 9256939505, "att": [ { "with": "wnfs://demouser.fission.name/public/photos/", "can": "wnfs/OVERWRITE" } ], "prf": [ {"iss": "did:key:...", "aud": "did:key:z6Mkr5aef...", ...} ] } 鍵A (iss) 鍵B (aud) 権限委任 wnfs/OVERWRITE 上位委任 (prf)
9. UCANで何ができる(予定だった)か 他ユーザやソフトに権限設定できる(TwitterのOAuth的用法) 主目的はおそらくクライアント認証 WordPressでいう「寄稿者」もLexiconで実現可能かも 署名鍵マスターをユーザが持ち、PDSに子鍵を使わせる(妄想) NIP-04の要領でDMの実現が容易に？ 子鍵発行とかをいい感じに行うために鍵管理システムも予定さ れていた
10. ATPの署名のおさらい 1. repositoryのMST rootに対する署名 2. did:plcのログに対する署名 一応ATPの外側なので詳細は触れない 3. com.atproto.server.createSessionのJWTに対する署名 PDSの署名鍵を使うのでユーザの鍵は無関係
11. UCANの使われどころ MST rootにUCANを含める commitへの署名鍵を選べる 公式ウェブサイトに定義がある auth_token: 《UCAN token》
12. 普通のrepository更新 1. クライアントがrecord作成 2. com.atproto.repo.createRecord等でPDSに作成要求 record作成不要なLexicon毎のAPIを使う可能性もある 3. PDSがrepositoryを更新してcommit作成
13. UCANを使ったrepository更新 1. クライアントがrepositoryを更新してcommit作成 repositoryは予めPDSと同期済の想定 2. com.atproto.sync.updateRepoでPDSにpush 複数commitまとめてpushしても良い 3. PDSがcommitを検証してマージ
14. R.I.P. 2023/01/06 実装に残っていたUCANライブラリ削除 "we weren't actually making use of this" 2023/01/25 実装からcom.atproto.sync.updateRepo削除 "doesn't make sense without client-held keys" 削除理由としては十分だが、明確に使わない方針へ
15. まとめ ADXはUCANのある未来を夢見ていた が、ATPは別の未来へ進んでいる UCANでも他でもいいけど権限管理機能欲しくない？
16. 余談：OAuth 2023/03/10 OAuth対応を求めるissueが立て続けに作成される #646 IndieAuth推し #649 OAuth WGから#646に触発されて参戦？ モチベーションはPDSの認証方式をATPで固定しないこと 外部のOAuthサーバで認証する話で、ターゲットが異なる とはいえそれは本来DID/SSIDが担うべき役割なのでは？ did:plcのsubjectはアカウント(だからユーザ認証不可)？
17. 余談：登録しない理由 検索の弱い/無いSNSにあまり価値を感じないため 基本的にトピックベースで情報収集したい 技術的興味とIndexerやLexiconへの期待からATPを追ってる 今登録したアカウントはdid:plcと共に消える可能性があるため 少なくとも現状の方針はDIDの変更を許さない せめてDIDドキュメント弄れれば他DIDと紐付けできるが……
18. 追記：気になったコメント 「did:plcはコンソーシアムで運営されるとMatrixに書いてた」 だとするとADXの図そのままの形になると思って良さそう placeholderのために大袈裟な気も多少するが…… ATPが鍵管理させない話について「Nostrではユーザが鍵管理してる」 実際Nostrは要求リテラシー（主に自己責任精神）高いと思う 投稿が揮発性なのでガチガチに固めなくてもいいというのもある？ repositoryの仕組みについて「gitっぽい」 実際意識してそうしているのは間違いない
19. 追記：ATPに期待すること① 公式アカウント（RSS代替） 自前でPDS運営できなくても保証しやすいはず did:webとhandle(DNS name)だとどっちが対応楽なんだろう サイト持ってなくても例えば他DIDからAlsoKnownAsできる DIDがもっと普及してくれないと厳しいか did:plcでは直接DIDドキュメント弄らせる気無さそうなの で、逆リンクはあんまり期待できない
20. 追記：ATPに期待すること② フォーラム・議論（BBS代替） Lemmy的な仕組みのLexiconがあればできそう ユーザ側がrecord持つのは厳しいので、他アカウントから投稿 するためのAPIとかが欲しくなる UCANが有ればユーザのPDS通さなくてもいけそう 正直ATPと相性良くはないが、ただただ欲しい どちらかというとDiscourse+APに期待すべきか？