Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ADXが見た夢(ATPのUCANの話)
Search
yamarten
March 25, 2023
Technology
0
290
ADXが見た夢(ATPのUCANの話)
Bluesky/ATProtocol 勉強会#0
https://www.youtube.com/watch?v=OjP0VkjRsC4&t=3052s
yamarten
March 25, 2023
Tweet
Share
More Decks by yamarten
See All by yamarten
Bluesky 2019〜2022
yamarten
1
170
PDS連合ことはじめ
yamarten
0
680
ATPの「A」
yamarten
0
250
Other Decks in Technology
See All in Technology
Reading Code Is Harder Than Writing It
trishagee
2
120
MIMEと文字コードの闇
hirachan
2
1.4k
コンピュータビジョンの社会実装について考えていたらゲームを作っていた話
takmin
1
590
2/18 Making Security Scale: メルカリが考えるセキュリティ戦略 - Coincheck x LayerX x Mercari
jsonf
0
110
データエンジニアリング領域におけるDuckDBのユースケース
chanyou0311
8
2.1k
Autonomous Database Serverless 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
17
45k
生成 AI プロダクトを育てる技術 〜データ品質向上による継続的な価値創出の実践〜
icoxfog417
PRO
5
1.9k
手を動かしてレベルアップしよう!
maruto
0
170
ESXi で仮想化した ARM 環境で LLM を動作させてみるぞ
unnowataru
0
160
偏光画像処理ライブラリを作った話
elerac
1
160
日経のデータベース事業とElasticsearch
hinatades
PRO
0
210
サイト信頼性エンジニアリングとAmazon Web Services / SRE and AWS
ymotongpoo
7
1.3k
Featured
See All Featured
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
10
510
Making the Leap to Tech Lead
cromwellryan
133
9.1k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Typedesign – Prime Four
hannesfritz
40
2.5k
RailsConf 2023
tenderlove
29
1k
How to train your dragon (web standard)
notwaldorf
91
5.9k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
430
Optimising Largest Contentful Paint
csswizardry
34
3.1k
Faster Mobile Websites
deanohume
306
31k
Large-scale JavaScript Application Architecture
addyosmani
511
110k
Visualization
eitanlees
146
15k
Transcript
ADXが見た夢 ATPのUCANの話 2023.3.17 Bluesky/ATProtocol 勉強会#0
自己紹介 Bluesky発足当時からたまに追ってた Matrixには入ってないのでブログやGitLab/GitHub追う程度 Bluesky Socialエアプ webや暗号は専門外
おことわり 規格概要は分かっている想定 規格の技術的な話だが、古い仕様の話なので実用的ではない 未来に復活する可能性も無くはない 疑問・ツッコミ・野次賛辞歓迎 資料公開時(or時間余ったら)ピックアップして補足予定
2022.10.18 ATP誕生
ADX? Authenticated Data eXperiment ATPの前身……というか開発段階の名前 当時のリポジトリでは色々夢を語っていたが、改名と共に削除 architecture.md 今見てみると方針変更もいくつかある
変わったもの UCANや鍵管理システムの主張が控えめに 仕様と実装に残りはしたが活用はされず DIDコンソーシアム→did:plcへ規模縮小 Lexiconによる機能拡張性
UCAN? 公開鍵間の推移的な権限委任を実現する仕様 https://ucan.xyz/ DID用OAuth 両者の公開鍵をJWTにまとめて署名 NostrのNIP-26と大体同じ原理
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)
UCANで何ができる(予定だった)か 他ユーザやソフトに権限設定できる(TwitterのOAuth的用法) 主目的はおそらくクライアント認証 WordPressでいう「寄稿者」もLexiconで実現可能かも 署名鍵マスターをユーザが持ち、PDSに子鍵を使わせる(妄想) NIP-04の要領でDMの実現が容易に? 子鍵発行とかをいい感じに行うために鍵管理システムも予定さ れていた
ATPの署名のおさらい 1. repositoryのMST rootに対する署名 2. did:plcのログに対する署名 一応ATPの外側なので詳細は触れない 3. com.atproto.server.createSessionのJWTに対する署名 PDSの署名鍵を使うのでユーザの鍵は無関係
UCANの使われどころ MST rootにUCANを含める commitへの署名鍵を選べる 公式ウェブサイトに定義がある auth_token: 《UCAN token》
普通のrepository更新 1. クライアントがrecord作成 2. com.atproto.repo.createRecord等でPDSに作成要求 record作成不要なLexicon毎のAPIを使う可能性もある 3. PDSがrepositoryを更新してcommit作成
UCANを使ったrepository更新 1. クライアントがrepositoryを更新してcommit作成 repositoryは予めPDSと同期済の想定 2. com.atproto.sync.updateRepoでPDSにpush 複数commitまとめてpushしても良い 3. PDSがcommitを検証してマージ
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" 削除理由としては十分だが、明確に使わない方針へ
まとめ ADXはUCANのある未来を夢見ていた が、ATPは別の未来へ進んでいる UCANでも他でもいいけど権限管理機能欲しくない?
余談:OAuth 2023/03/10 OAuth対応を求めるissueが立て続けに作成される #646 IndieAuth推し #649 OAuth WGから#646に触発されて参戦? モチベーションはPDSの認証方式をATPで固定しないこと 外部のOAuthサーバで認証する話で、ターゲットが異なる
とはいえそれは本来DID/SSIDが担うべき役割なのでは? did:plcのsubjectはアカウント(だからユーザ認証不可)?
余談:登録しない理由 検索の弱い/無いSNSにあまり価値を感じないため 基本的にトピックベースで情報収集したい 技術的興味とIndexerやLexiconへの期待からATPを追ってる 今登録したアカウントはdid:plcと共に消える可能性があるため 少なくとも現状の方針はDIDの変更を許さない せめてDIDドキュメント弄れれば他DIDと紐付けできるが……
追記:気になったコメント 「did:plcはコンソーシアムで運営されるとMatrixに書いてた」 だとするとADXの図そのままの形になると思って良さそう placeholderのために大袈裟な気も多少するが…… ATPが鍵管理させない話について「Nostrではユーザが鍵管理してる」 実際Nostrは要求リテラシー(主に自己責任精神)高いと思う 投稿が揮発性なのでガチガチに固めなくてもいいというのもある? repositoryの仕組みについて「gitっぽい」 実際意識してそうしているのは間違いない
追記:ATPに期待すること① 公式アカウント(RSS代替) 自前でPDS運営できなくても保証しやすいはず did:webとhandle(DNS name)だとどっちが対応楽なんだろう サイト持ってなくても例えば他DIDからAlsoKnownAsできる DIDがもっと普及してくれないと厳しいか did:plcでは直接DIDドキュメント弄らせる気無さそうなの で、逆リンクはあんまり期待できない
追記:ATPに期待すること② フォーラム・議論(BBS代替) Lemmy的な仕組みのLexiconがあればできそう ユーザ側がrecord持つのは厳しいので、他アカウントから投稿 するためのAPIとかが欲しくなる UCANが有ればユーザのPDS通さなくてもいけそう 正直ATPと相性良くはないが、ただただ欲しい どちらかというとDiscourse+APに期待すべきか?