Daniel Holmgren · The Atproto Spaces Alpha is Live
08-20
Atproto Spaces, formerly known as “the permissioned data protocol,” is a new extension to atproto that enables non-public data.
AT Protocol 観測 / 2026-08-19 時点 · 2026-10-08 追記
非公開データのためのプロトコル提案。半年で草案から実装アルファへ進んだが、名前も、権威の所在も、まだ決着していない。
Bluesky の投稿は、いまは全部が公開だ。誰でも読めるし、どのアプリからでも取り出せる。決まった人にだけ見せる、という使い方はできない。それを変える仕組みが atproto spaces だ。
スペースは部屋のようなものだ。部屋の持ち主が、誰を入れるかを決める。部屋に書いたものは、入れてもらった人と、許されたアプリにしか読めない。ただし暗号にはしないので、データを預かるサーバーやアプリの運営者は中身を読める。名前は「permissioned data（許可されたデータ）」から atproto spaces に決まった。
8月20日から、開発者向けの試験版が動いている。更新は木曜に出て、中身はたびたび変わる。Bluesky の開発者の見込みでは、一般に使えるようになるのは11月中旬ごろだ。招かれた部屋をどうやって知るか、部屋に書いたものをあとから公開できるかは、まだ決まっていない。Bluesky のアプリにも「spaces」という名前の機能の試作があり、紛らわしいという声が出ている。
詳しいことは下の「追記」と、8月19日時点の記録に書いてある。
8月19日以降の動きを足した。この節のあとは8月19日時点の記録で、手を入れていない。
名前は atproto spaces に決まった。レコードの権威は作成者に残り、1つのレコードを複数のスペースに属させる案は採られなかった。一般公開の目安は11月中旬だ。
8月20日の公式ブログはこう書き出している。
Atproto Spaces, formerly known as “the permissioned data protocol,” is a new extension to atproto that enables non-public data.
9月28日に提案本文の題も「0016 Atproto Spaces」になった（proposals PR #115「Consistently rename to atproto spaces」）。ディレクトリ名は 0016-permissioned-data のままだ。実装 PR #5187 の題も「Atproto spaces」に変わっている。
10月7日には別の重なりが出た。Bluesky の @alexbenzer.com が、アプリ内のコミュニティ機能の試作を「spaces」として見せた（♡284・🔁82・💬50）。@jimray.bsky.team は「Spaces are, of course, being designed on top of atproto spaces.」と補っている。
y'all should figure out a different name because i don't think it's good for there to be atproto spaces and bluesky spaces
@alexbenzer.com はリプライで「is there another name you think would work better?」と返している。プロトコルの名前は決まったが、アプリの機能の名前はまだ決まっていない。
提案本文の比較表に答えがある。レコードの権威は公開データと同じく作成者の DID に残り、URI の権威だけがスペースの DID に移る。
| Public broadcast | Atproto spaces | |
|---|---|---|
| Record authority | User DID | User DID |
| URI authority | User DID | Space authority DID |
| Addressing | Traditional at:// URI | at:// URI with space segment |
URI スキームは at:// のままだ。レコードは at://{spaceDid}/space/{spaceType}/{skey}/{authorDid}/{collection}/{rkey} と書く。
1つのレコードを複数のスペースに属させる案は採られなかった。@dholms.at は8月27日の Reintroducing Spaces で、この案を Google+ の Circles と同じ種類のものとして扱っている。
I don't believe that any variation on circles (ACLs, the full fluid expression, or just allowing records to surface in multiple spaces) gives that to us.
同じ記事は、改名で重心を「who can see what」から「locality」へ移したと書いている。@chrisshank.com が立てたフォーラムのスレッドは3件で止まっていて、3件とも本人の書き込みだ。@bnewbold.net が予告した長文の応答は、10月8日の時点で見つからなかった。
アルファ公開
試験用の PDS、Docker イメージ ghcr.io/bluesky-social/atproto:pds-spaces-alpha、見本アプリ bulletin.my が出る。更新は木曜に出す。
工程の見込み
@bnewbold.net がフォーラムに出す（下の表）。
最初の破壊的変更
simplespace の書き込み権限が読み取り権限から分かれる。policy は readPolicy／writePolicy に、addMember は putMember になる。
共同体の標準案 opensocial.group
tangled に出る。atproto spaces の上に、メンバー・役割・発見・モデレーションを決める。
2回目の破壊的変更
credential の鍵の証明は DPoP をやめ、HTTP Message Signatures（RFC 9421）を使う。有効期限が短くなり、失効の手段が入る。スペースホストが書き込み通知に順番を付ける。
Bluesky のアプリ内コミュニティ「spaces」の試作
8月19日の記録に書いた cnf.jkt（DPoP）は、10月1日から cnf.kid になっている。
9月9日に @bnewbold.net が出した見込みは次のとおりだ（フォーラム）。
| 月 | 予定 |
|---|---|
| 9月 | 設計を試し、大きな問題を見つける。アーキテクチャを議論できる最後の期間 |
| 10月 | 提案を改訂して仕様の草案に近づける。破壊的変更はまとめて入れる |
| 11月 | 主な PDS 運営者で「general availability」の日を合わせる。仕様・SDK・参照 PDS をそろえる |
| 12月 | 運用で出た問題に対応し、開発者向けの資料を整える |
I would ask that application developers and service providers not publicly launch production features that rely on spaces data, services, or lexicons until the protocol is “general availability”.
Bluesky での要約は「around mid-November」だ（投稿）。
レコードは作成者、URI はスペース。複数スペースへの所属は採らない。
listSpaces の説明は「The spaces the caller holds a repo in.」のままだ。招待は共同体の標準案に「invites」スペースとして入っていて、プロトコルには入っていない。
提案本文に手段はない。Reintroducing Spaces は、レコードごとに読み手を変える使い方に spaces は「least tuned」だと認めている。
credential の有効期限は既定10分・最大60分になった。スペースの権威者は notifyCredentialRevoked で、発行済みの credential を jti ごとに失効させられる。送るかどうかは権威者が決める。
| プロジェクト | 内容 | 状態 |
|---|---|---|
| PR #5187 | 本体。題は「Atproto spaces」 | Draft・163コミット・10-01 更新 |
| PR #5423 | alpha 公開ブランチ。題は「Atproto spaces alpha」 | Draft・19コミット |
| 公式ブログが挙げた実装 | ZDS（Zig）、atproto-crates PDS（Rust）、rsky PDS（Blacksky）、HappyView | 08-20 時点 |
| vlPDS | @jaz.sh が alpha に全面対応と発表 | 10-06 |
| pds.rip | 7日で消える試験環境。spaces alpha で動く | 09-24 |
この件でいちばん広まった投稿は日本語だった。8月21日の @tkusano.jp で、♡564・🔁699。公式の @atproto.com の発表（♡342・🔁123）よりリポストが多い。
8月31日には @tokimeki.blue が、Community DID でチームの運用を試す TOKIMEKI Space を出している。
app.bsky.feed.searchPosts で atproto spaces／permissioned data／permissioned spaces を8月19日以降について検索し、重複を除いて589件を見た。そこから提案本文（proposals の 0016 とコミット履歴）、PR #5187／#5423、フォーラムの3スレッド、公式ブログ、Reintroducing Spaces に当たった。エンゲージメントの数は10月8日に取った値だ。
2026年2月から8月にかけて、AT Protocol にアクセス境界を持つデータのプロトコルを足す提案が進んでいる。7月3日に正式提案が公開され、8月18日にアルファ実装ブランチが立った。だが同じ8月18日、提案者自身が名前に取り消し線を引いた。名称の揺れは表面で、下では「レコードの権威をリポジトリとスペースのどちらが持つか」という設計の分岐が開いている。
8月18日、@dholms.at（Daniel Holmgren、Bluesky）が名前を打ち消した投稿をした。2026年1月に「p̶r̶i̶v̶a̶t̶e̶ permissioned data」と書いたときと同じ形式だ。前回は private を捨てて permissioned を採った。今回は permissioned data 全体を捨てようとしている。
permissioned data atproto spaces
リプライの大半は言葉遊びだった（@cuducos.me の「略して ass」、@zzstoatzz.io の「atproto spaces のアナグラムは astrocat popes」）。だが前日から、名前ではなく設計を問う筋が立っていた。
I have a feeling that the framing of permissioned spaces is leading us down the route of a different URI scheme and the space as an authority, where as permissioned data acknowledges this is all the same scheme and records can consensually travels between many potential spaces.
名前が「データ」から「スペース」へ移ると、権威の所在も移る。レコードが属する先がリポジトリではなくスペースになり、別のURIスキームを呼び込む。@bnewbold.net（Bryan Newbold、Bluesky）はこれに同意していない。「ライフサイクルを通じて同じ方法で参照・同期されるべきだとは思わない。共通のスキーマ／表現を持つことが主な利点だ」と返し、続けて「詳細はリプライではなく長文で応じたい」と述べた。議論はフォーラムの新スレッドへ移っている。
パーミッションドデータは、既存のパブリック・ブロードキャスト・プロトコル（通常のリポジトリ同期）とは別の、アクセス境界を持つデータのための独立したプロトコルだ。個人データ（ブックマーク、ミュート、下書き）、ゲート付きコンテンツ（有料ニュースレター）、非公開投稿、グループチャットを想定している。
提供するのはアクセス制御であって機密性ではない。エンドツーエンド暗号化ではないと提案本文に明記されており、PDSと認可済みアプリケーションはデータを平文で読める。検索・通知・集約・モデレーションといったサーバー側機能を成立させるためだ。
| 概念 | 提案本文での定義 |
|---|---|
| space | 共有された社会的文脈を表す、認可と同期の境界。(authority DID, space type NSID, space key) の3値で識別する |
| permissioned data | アクセス境界を持つデータ |
| space credential | スペース全体への鍵。保持者は全メンバーのレコードを読めるが、メンバーリストの変更・書き込み権限は付かない |
| policy | 誰に credential を出すか。#memberListPolicy（既定・明示的なDIDロースター）／#publicPolicy／#managingAppPolicy |
| appAccess | どのクライアントアプリが保持できるか。#open（既定）／#allowList |
credential（atproto-space-credential+jwt）には cnf.jkt が追加された。RFC 9449 DPoP による鍵所持証明のサムプリントで、単なる bearer トークンとして傍受・再生されるリスクへの対策だ。受け取ったホストはリクエストごとに鍵の所持を再証明させられる。
@dholms.at は2月から Diary シリーズを連載している。全9本、うち7本が本編だ。Attie のまとめは6月以降しか拾っていないが、設計判断の多くは2〜5月に確定している。
Diary 1: To Encrypt or Not to Encrypt
暗号化するかどうかの判断。ここで E2EE をスコープ外に置く方針が決まる。
Diary 2: Buckets / Diary 3: Your Bucket, My Data
当初の単位は「バケット」だった。
Interlude: Spaces
単位がバケットからスペースへ変わる。8月の改名提案はここまで遡る。番号を振らない「幕間」として出されている。
Diary 4: The Big Picture
2026年春ロードマップ公開
Blacksky・Northsky・Habitat の各チームが並行して実装に取り組むと記載。「permissioned data は夏を通じて protocol team の主要な取り組みになる」と予告している。
Diary 5: What's in a Name?
URI構造の検討。スペースに固有DIDを切る判断が核だ。Feeds が作成者DIDに紐づいて譲渡不能になった失敗を繰り返さないための設計であり、所有権の移転可能性が識別子の独立性を要求する。
lexicon 第一版のフィードバック募集
コミュニティのモデル化 / Diary 6: Boring Auth
同時期に OAuth スコープ選択を補助するツールも公開された。
提案PRの早期草案を公開
「過度に重視しないでほしい、用語・詳細・挙動はすべて変わる可能性が高い」と注記。♡275・🔁66。翌日には AMA ライブ配信が行われた。
URIスキームの再検討
一度は別スキームに傾いたが at:// への回帰を検討していると報告し、フォーラムへ誘導。8月の論争はここから連続している。
実装PR #5187 作成（Draft）
公開の前日に実装が始まっていた。@atproto/space・lexicon・pds・repo・common・oauth-provider-ui・dev-env にまたがる。8月19日時点で100コミット、@bnewbold.net がレビュー中。
提案 0016-permissioned-data 正式公開
@pfrazee.com（Paul Frazee）が「非公開グループ・コミュニティを可能にする大きなアップグレードになる」と評価。♡275・🔁56。
Blacksky が「Blacksky限定投稿」を公開
この件で最も反応の大きい投稿（♡511・🔁174・📝73）。ただしこの時点では独自実装であり、公式仕様ではない。
Diary 7: Off the Record（本編最終回）
パーミッションド・リポジトリ自体の構造・署名・同期を扱う。同日、@bnewbold.net が「2年前の今日、dholms がグループのURIスキームを考えていた」と振り返っている。
発見可能性の問題が提起される
@offline.arushibandi.com が「listSpaces は自分が書き込んだスペースしか返さない」と指摘。→ 未決着の論点
Bulleted 公開
@ngerakines.me のアウトライナー。すべての箇条書きが自分のリポジトリのレコードになる。♡111。
Space Access 解説 / Habitat が sap を公開
@ngerakines.me が credential 発行の2軸（policy／appAccess）を解説。同日 @habitat.network が permissioned spaces を同期する Go パッケージ sap を公開し、複数チームでテスト中と述べている。
Blacksky が公式仕様へ移行
独自実装から1か月で permissioned spaces 仕様そのものを実装した。♡144。
We implemented the new permissioned spaces spec. This is a step in the direction for making Blacksky-only posts work for our users in any app. It is also a strong signal to our Acorn customers that their access-control gated community feeds aren't proprietary to Blacksky and work even if they leave
アルファ公開ブランチ / 改名の提示
ブランチ permissioned-data-alpha と PR #5423 が立つ。@dholms.at はこれを「alpha publishing branch」と説明した。マージすると alpha 版 npm パッケージが公開されるもので、ブランチ自体は4月から断続的に動いていたという。同日、改名の投稿。
blob の扱いが論点化
@brookie.blog：レコードは軽くスペース外へ出しやすいが blob は重い。blob の可視性を導出にして、公開レコードから参照されるまではスペース内に留める案を提示（♡15）。
提案は公開済みで実装も動いているが、設計の中核に開いた問いが残っている。いずれも8月に入って提起され、まだ結論が出ていない。
@chrisshank.com は「レコードが存在するとき、スペースがリポジトリより大きな権威を持つ」構造を問題視する。同じレコードを複数のスペースで共有しようとすると、現在の設計ではスペースごとに新規レコードを作る必要があり、オブジェクトの永続性が壊れる。レコードを「スペースによって認可される」ものと捉え直し、1つのレコードが0〜n個のスペースに属せるようにする案が出ている。
@bnewbold.net は懐疑的だ。「ライフサイクルを通じて同じ方法で参照・同期されるべきだとは思わない。共通のスキーマ／表現を持つことが主な利点だ」。長文での応答を予告している。
listSpaces は自分が書き込んだスペースしか返さない。誰かに招かれても、書き込むまで発見できない。@dholms.xyz はプロトコル層の通知機構を不要とする立場で、スパム防止とメンバーシップの曖昧さを理由に挙げ、アプリケーション層での解決を主張する。@sashankg.bsky.social は相互運用性を理由に反論し、スペースホスト側のエンドポイントを提案している。
@iame.li（Eli Mallon）は「これを常時やる必要が出てきている」と述べる。現状の選択肢は、スペースの内と外で同じレコードを二度公開することだけだ。@bnewbold.net はここでも「長文の回答に値する」と応じ、対面での議論を提案している。
スペースからメンバーを外しても、既に発行された credential は無効にならない。止まるのは将来の発行だけだ。@phi.zzstoatzz.io は付与の側にも同じ非対称があると指摘する。鍵を渡す行為は「締め出されなくなる」と「いつ帰宅したかを正確に知られる」の2つの記述を同時に真にする。付与と失効は反対語に見えて、どちらも片側にずれている。
| プロジェクト | 内容 | 状態 |
|---|---|---|
| bluesky-social/atproto PR #5187 |
本体実装。@atproto/space ほか7パッケージ | Draft 100コミット・レビュー中 |
| PR #5423 | #5187 の alpha 公開ブランチ。マージで npm alpha 版が出る | Draft 08-18 作成 |
| Blacksky | 限定投稿。7月は独自実装、8月15日に公式仕様へ移行 | 稼働中 |
| Habitat sap | permissioned spaces を同期する Go パッケージ | 公開 複数チームがテスト中 |
| Bulleted | アウトライナー。space 対応。他人が枝に追記できる | 稼働中 |
| space proxy | simplespace 実験用 PDS ラッパー | 実験 |
| chalky.rown | HappyView の space API を使ったカレンダー | 実験 |
「permissioned-data は実験的である。データ損失の実際のリスクとデータ漏洩の実際のリスクがある。人々はこれを非公開で安全・安心なコンテンツとして扱いたくなるだろうが、まだそうすべきではない。そしてこれはエンドツーエンド暗号化の代替にはならない」
@ngerakines.me 08-14 · @bmann.ca が引用（「だからこそ今、開発者にテストしてほしい」）
アクセス制御と機密性は別物であるという原則により、PDSと認可済みアプリケーションはデータを平文で読める。E2EE はこの提案の範囲外で、必要ならアプリケーション側で別途重ねることになる。
@chris.pardy.family は別の懸念を出している。atproto が十分に大きくなったとき、Google・Microsoft・Apple が PDS をホストしない理由がない。ホスティング費用は彼らにとって誤差であり、見返りに全ユーザーのパーミッションドデータのリポジトリへアクセスできる。@kandake.africa はモノリシックな AppView にデータを置く現状を問題視し、ユーザーごとのスペースへ移すべきだと主張している。
継続的に追っているのは @yamarten.bsky.social がほぼ唯一だ。#ATプロトーク のリンク集で実装プロジェクトを毎週まとめており、上の実装一覧のうち space proxy・chalky.rown はここからしか辿れなかった。
8月16日には「permissioned data のコミュニティ実装が相当進んでいて驚くけど、公式なタイムラインどうなってるのだろうね。本当に来月だかには Bluesky に載せるつもりなのだろうか」と書いている。8月18日の PR #5423 についても「暫く別ブランチとしたまま運用しようとしている感じかね。あくまで試験的運用として仕様を確定させたくないとかあるのかもしれない」と、性格を正しく読んでいる。
8月7日の観察も筋がいい。「permissioned data が普及したら firehose からアプリを捕捉するのは難しくなりそう……と思ってたけど、lexicon 発行（少なくとも space type）が求められるから逆に楽になるのかもしれない」。
Bluesky の app.bsky.feed.searchPosts（要認証）で全文検索し、投稿から一次資料へ辿った。Attie の同主題ページとの差は、入口の数と一次資料の有無から出ている。
日付はすべて UTC で揃えた。Bluesky の createdAt は UTC であり、日本時間で表示すると1日ずれる投稿がある。Attie の年表との日付の食い違いはこれが原因のものを含む。
エンゲージメント数値は 2026-08-19 時点の取得値だ。