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
690
ATPの「A」
yamarten
0
250
Other Decks in Technology
See All in Technology
LangGraph × Bedrock による複数の Agentic Workflow を利用した Supervisor 型のマルチエージェントの実現/langgraph-bedrock-supervisor-agent
ren8k
3
410
AWSアカウントのセキュリティ自動化、どこまで進める? 最適な設計と実践ポイント
yuobayashi
7
2k
プルリクエストレビューを終わらせるためのチーム体制 / The Team for Completing Pull Request Reviews
nekonenene
4
2k
IAMのマニアックな話2025
nrinetcom
PRO
6
1.6k
開発組織を進化させる!AWSで実践するチームトポロジー
iwamot
2
630
開発者体験を定量的に把握する手法と活用事例
ham0215
0
160
DeepSeekとは?何がいいの? - Databricksと学ぶDeepSeek! 〜これからのLLMに備えよ!〜
taka_aki
2
210
最近のSRE支援ニーズ考察 | sogaoh's LT @ Road to SRE NEXT@札幌
sogaoh
PRO
1
170
2025/3/1 公共交通オープンデータデイ2025
morohoshi
0
120
OSSの実装を参考にBedrockエージェントを作る
moritalous
2
350
AI-Driven-Development-20250310
yuhattor
3
320
フォーイット_エンジニア向け会社紹介資料_Forit_Company_Profile.pdf
forit_tech
1
1.7k
Featured
See All Featured
Practical Orchestrator
shlominoach
186
10k
Building Your Own Lightsaber
phodgson
104
6.3k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
A better future with KSS
kneath
238
17k
Into the Great Unknown - MozCon
thekraken
35
1.7k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
Agile that works and the tools we love
rasmusluckow
328
21k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
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に期待すべきか?