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
330
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
210
PDS連合ことはじめ
yamarten
0
780
ATPの「A」
yamarten
0
270
Other Decks in Technology
See All in Technology
MCPで変わる Amebaデザインシステム「Spindle」の開発
spindle
PRO
3
3.2k
下手な強制、ダメ!絶対! 「ガードレール」を「檻」にさせない"ガバナンス"の取り方とは?
tsukaman
2
440
【実演版】カンファレンス登壇者・スタッフにこそ知ってほしいマイクの使い方 / 大吉祥寺.pm 2025
arthur1
1
840
Platform開発が先行する Platform Engineeringの違和感
kintotechdev
4
570
ガチな登山用デバイスからこんにちは
halka
1
240
Practical Agentic AI in Software Engineering
uzyn
0
110
COVESA VSSによる車両データモデルの標準化とAWS IoT FleetWiseの活用
osawa
1
280
AIのグローバルトレンド2025 #scrummikawa / global ai trend
kyonmm
PRO
1
280
初めてAWSを使うときのセキュリティ覚書〜初心者支部編〜
cmusudakeisuke
1
250
allow_retry と Arel.sql / allow_retry and Arel.sql
euglena1215
1
170
5分でカオスエンジニアリングを分かった気になろう
pandayumi
0
240
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
3
250
Featured
See All Featured
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Typedesign – Prime Four
hannesfritz
42
2.8k
Side Projects
sachag
455
43k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.7k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
188
55k
Making the Leap to Tech Lead
cromwellryan
135
9.5k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Thoughts on Productivity
jonyablonski
70
4.8k
The Straight Up "How To Draw Better" Workshop
denniskardys
236
140k
A Tale of Four Properties
chriscoyier
160
23k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
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に期待すべきか?