atproto spaces概要

ATプロトーク 2026-07-19 + 2026-08-16
https://www.bluecast.app/user/@yamarten.bsky.social

Transcript

1. atproto spaces概要 atprotoの秘密の話 ATプロトーク解説資料
2. 今回話すこと proposal 0016(2026/08時点)に基づくspace仕様案概要 典型的な通信フロー 認証手段各種 simplespace概要 識別子の割り当て方 permissioned repositoryのデータ構造 以下のことは話さない コミュニティ仕様/実装案(arbiter等) 具体的な用途
3. 概況 (2026-08-23) アルファ版がリリースされ、一部PDSで利用可能に リファレンス実装はデフォルトでは無効 コミュニティレベルでは実装が始まっている HappyViewのsimplespace実装 Habitatによる実験用PDSラッパー 独自のspace host実装(Arbiter) 対応PDS実装: rsky(Blacksky), pds.js, zds, etc. 対応サービス: bulletin, Bulleted, リト, plyr.fm, secretsky
4. 構成要素 クライアント spaceアクセスのOAuthスコープを持つ syncer PDS (repo host) ※認可サーバーは割愛 所属ユーザーのpermissioned repositoryを 保持する space host spaceのアクセス権や全体設定を管理する syncer spaceのデータを保持するクライアント 用途的にはappviewに近い space user1 user2 space A space A PDS PDS PDS PDS user.example.com public space A space B
5. 書き込み ① クライアントが自PDSに書き込み クライアントはOAuth認証済みとする syncer ④ ⑤ ③ ② PDSはpermissioned repositoryを更新 ③ PDSからspace hostに更新通知 ④ space hostからsyncerに更新通知(任意) ⑥ space PDS PDS PDS PDS ⑤ syncerが対象PDSにデータ要求(任意) 必要に応じてspace hostにPDS一覧を要求 syncerはspaceアクセス権を獲得済みとする ⑥ syncerが対象PDSからデータ取得(任意) ① ②
6. 読み出し ① クライアントがPDSにspaceアクセスを要求 ② PDSはscopeを確認し、delegation token発行 syncer space ③ クライアントがspace hostにspaceアクセス を要求 delegation tokenに加え、client attestationも使う場合がある PDS ③ ④ space hostが独自の基準で判断し、space credentialを発行 ⑤ クライアントが各メンバーPDSにデータ要求 ⑥ PDSが要求されたpermissioned dataを返却 ① ② PDS PDS ④ PDS ⑤ ⑥
7. 認証 認証情報 発行者 OAuth access token auth server (多くの場合PDS) delegation token readerの所属PDS client attestation readerクライアント space credential space host 検証者 何を示すか 標準寿命 reader/writerの 対象spaceに対応する 2週間 所属PDS スコープ有無 (最大180日) space host アクセスを要求して いるアカウント space host 未規定 アクセスするアプリ (例では1分) 各メンバーPDS spaceアクセス許可 1分 (任意) 2時間 (任意) space hostによる認証の基準は実装依存である点に注意 space credentialには部分的な許可は無く、常にspace全体を読める
8. 権限/OAuthスコープ 新しくspace permission(スコープ)が追加 対象のspaceをパーツ毎に指定できる アクセス権限はactionパラメータで指定 (同様に、space作成などの管理権限はmanageパラメータで指定) read: space全体の読み出し read_self: 自分のpermissioned repoのみ読み出し create: 自分のpermissioned repoのrecord追加 update: 自分のpermissioned repoのrecord更新 delete: 自分のpermissioned repoのrecord削除
9. simplespace space credentialの判定やspaceの管理APIは各space hostの実装依存 simplespaceはPDSに実装必須な管理API仕様 認可 全許可(公開)/所属メンバーのみ許可/管理アプリに委任 加えて、アクセス可能なクライアントのホワイトリストが持てる 管理API crateSpace/deleteSpace: spaceの作成/削除 updateSpace: 上記の認可設定変更 addMember/removeMember/listMembers: 指定spaceのメンバー管理
10. 識別子 at://did:example:host/ space/example.space/ 3mszi3sr7ssdl permissioned dataやspaceはat-uriを持つ at://{spaceDid}/space/{spaceType}/{skey}/ {authorDid}/{collection}/{rkey} syncer spaceDiD: space authority(≒管理者)のDID space user1 user2 space A space A spaceType: spaceのlexiconを示すNSID 具体的なlexicon型は後述 skey: space host内のspaceを識別するキー PDS PDS PDS PDS user.example.com public space A space B 構文はrkeyと同じ(つまり典型的にはTID) その他: permissioned data所有者(≠space host)のDID/collection/rkey at://did:example:host/ space/example.space/ 3mszi3sr7ssdl/ did:example:user/ com.example.data/ 3mt3rtakxef22
11. at-uriからrecord取得フロー 1. spaceDidを解決し、DIDドキュメントからspace host情報を取得 #atproto_space_hostおよび#atproto_spaceがあればそれを使う 無ければ#atproto_pdsと#atprotoを使う 2. space hostからspace credentialを取得 目的がspace情報の場合はここでspace hostのAPIを使って終わり 3. authorDidを解決し、DIDドキュメントからPDS情報を取得 4. space credentialを使ってPDSからrecord取得 つまり、PDSがspace hostの場合は、authorDidに何も手を加えずに spaceDidとしても使うことができる
12. space type lexiconで宣言し、spaceが持てるcollectionやskeyの型を決める collectionはヒントであって強制力は無い点に注意 nameはOAuth承認時に提示され、多言語化できる descriptionは開発者向けの用途説明で、ユーザーには見えない { } "lexicon": 1, "id": "com.atmoboards.forum", "defs": { "main": { "type": "space", "description": "A discussion forum", "key": "any", "name": "AtmoBoards Forum", "name:lang": { "es": "Foro AtmoBoards", "ja": "AtmoBoards 掲示板" }, } } "collections": ["com.atmoboards.thread", "com.atmoboards.reply"]
13. permissioned repository構造 record集合(CBOR連想配列)、そのハッシュ(LtHash)、関連blobを持つ LtHashは耐量子安全性を持ち、差分操作が可能 公開repositoryと異なり、permissioned repositoryはMSTを持たない 用途ごとに独立repoになるので、部分同期する動機が薄い PDSから直接取得するため、悪意による欠落を検証しなくてよい permissioned repositoryに対して署名は付与しない 他メンバーが署名とともにデータを公開すると「space内にその データが実在すること」が証明できてしまう 通信時に二者間で署名は使うが、データ本体に直接署名しない
14. syncerによる同期 syncerは同期するという機能を持ったクライアントであり、認証など は普通のクライアントと区別されない そのsyncerを利用するメンバーの認証情報を使う 2時間毎に誰かしらの承認があればspace全体の同期が可能 space hostの通知登録APIにより、更新通知を受けることがある 通知機能実装も利用も任意 同期開始時のためにspace hostはrepository一覧を示す場合がある 典型的には、検索機能やモデレーションサービスを提供するサーバーが syncerになると思われる
15. 参考資料 space(permissioned data)仕様案 https://github.com/bluesky-social/proposals/blob/main/0016permissioned-data/README.md 実装ブランチ https://github.com/bluesky-social/atproto/tree/permissioneddata 開発ブログ https://dholms.leaflet.pub/3meluqcwky22a アルファリリース告知 https://atproto.com/blog/atproto-spaces-alpha