Permissioned Data atproto spaces #
AT Protocol の非公開データ提案、2026年8月19日時点の観測記録（10月8日に追記）
半年で草案から実装アルファへ進んだ。だが名前も、権威の所在も、まだ決着していない。
調査：Nighthaven（moja.blue）／ 日付はすべて UTC
体裁を整えた版が
atproto-spaces.htmlにある。ダウンロードしてブラウザで開けば、時系列レールと色分けの付いた形で読める。
いまどうなっているか（2026年10月8日） #
Bluesky の投稿は、いまは全部が公開だ。誰でも読めるし、どのアプリからでも取り出せる。決まった人にだけ見せる、という使い方はできない。それを変える仕組みが atproto spaces だ。
スペースは部屋のようなものだ。部屋の持ち主が、誰を入れるかを決める。部屋に書いたものは、入れてもらった人と、許されたアプリにしか読めない。ただし暗号にはしないので、データを預かるサーバーやアプリの運営者は中身を読める。名前は「permissioned data（許可されたデータ）」から atproto spaces に決まった。
8月20日から、開発者向けの試験版が動いている。更新は木曜に出て、中身はたびたび変わる。Bluesky の開発者の見込みでは、一般に使えるようになるのは11月中旬ごろだ。招かれた部屋をどうやって知るか、部屋に書いたものをあとから公開できるかは、まだ決まっていない。Bluesky のアプリにも「spaces」という名前の機能の試作があり、紛らわしいという声が出ている。
詳しいことは下の「追記」と、8月19日時点の記録に書いてある。
追記：2026年10月8日時点 #
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.
出典：Daniel Holmgren, The Atproto Spaces Alpha is Live
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.」と補っている。
@mary.my.id ♡26 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日の時点で見つからなかった。
アルファの進み方 #
| 日付 | 出来事 |
|---|---|
| 08-20 | アルファ公開 試験用の PDS、Docker イメージ ghcr.io/bluesky-social/atproto:pds-spaces-alpha、見本アプリ bulletin.my が出る。更新は木曜に出す |
| 09-09 | @bnewbold.net が工程の見込みをフォーラムに出す（下の表） |
| 09-10 | 最初の破壊的変更。simplespace の書き込み権限が読み取り権限から分かれる。policy は readPolicy／writePolicy に、addMember は putMember になる |
| 09-24 | 共同体の標準案 opensocial.group が tangled に出る。atproto spaces の上に、メンバー・役割・発見・モデレーションを決める |
| 10-01 | 2回目の破壊的変更 credential の鍵の証明は DPoP をやめ、HTTP Message Signatures（RFC 9421）を使う。有効期限が短くなり、失効の手段が入る。スペースホストが書き込み通知に順番を付ける |
| 10-07 | 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”.
出典：
@bnewbold.net09-09 · Permissioned Data Spaces Protocol Timeline
Bluesky での要約は「around mid-November」だ（投稿）。
4点のその後 #
| 論点 | 10月8日の状態 |
|---|---|
| 1. 権威 | 決着。レコードは作成者、URI はスペース。複数スペースへの所属は採らない |
| 2. 追加されたスペースの発見 | 未決着。listSpaces の説明は「The spaces the caller holds a repo in.」のままだ。招待は共同体の標準案に「invites」スペースとして入っていて、プロトコルには入っていない |
| 3. スペースから公開へ | 未決着。提案本文に手段はない。Reintroducing Spaces は、レコードごとに読み手を変える使い方に spaces は「least tuned」だと認めている |
| 4. 失効 | 一部変わった。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）よりリポストが多い。
@tkusano.jp ♡564 · 🔁699 Blueskyで鍵機能を使えるようにするのに必要な技術のアルファテストが始まりました。 投稿
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 全体を捨てようとしている。
@dholms.at ♡117 · 🔁7 · 💬10 · 📝4
permissioned dataatproto spaces 投稿
リプライの大半は言葉遊びだった（@cuducos.me の「略して ass」、@zzstoatzz.io の「atproto spaces のアナグラムは astrocat popes」）。だが前日から、名前ではなく設計を問う筋が立っていた。
@chrisshank.com ♡7 · 8月17日 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本が本編だ。設計判断の多くは2〜5月に確定している。
| 日付 | 出来事 |
|---|---|
| 02-11 | Diary 1: To Encrypt or Not to Encrypt 暗号化するかどうかの判断。ここで E2EE をスコープ外に置く方針が決まる |
| 02-26 03-12 |
Diary 2: Buckets / Diary 3: Your Bucket, My Data 当初の単位は「バケット」だった |
| 03-17 | Interlude: Spaces 単位がバケットからスペースへ変わる。8月の改名提案はここまで遡る。番号を振らない「幕間」として出されている |
| 03-20 | Diary 4: The Big Picture |
| 03-24 | 2026年春ロードマップ公開。Blacksky・Northsky・Habitat が並行して実装に取り組むと記載。「permissioned data は夏を通じて protocol team の主要な取り組みになる」と予告 |
| 05-08 | Diary 5: What's in a Name? URI構造の検討。スペースに固有DIDを切る判断が核だ。Feeds が作成者DIDに紐づいて譲渡不能になった失敗を繰り返さないための設計であり、所有権の移転可能性が識別子の独立性を要求する |
| 05-28 | lexicon 第一版のフィードバック募集 |
| 06-02 06-05 |
コミュニティのモデル化 / Diary 6: Boring Auth |
| 06-23 | 提案PRの早期草案を公開。「用語・詳細・挙動はすべて変わる可能性が高い」と注記。♡275・🔁66。翌日 AMA ライブ配信 |
| 07-01 | URIスキームの再検討。一度は別スキームに傾いたが at:// への回帰を検討と報告 |
| 07-02 | 実装PR #5187 作成（Draft） 提案公開の前日に実装が始まっていた。 @atproto/space・lexicon・pds・repo・common・oauth-provider-ui・dev-env にまたがる。8月19日時点で100コミット、@bnewbold.net がレビュー中 |
| 07-03 | 提案 0016-permissioned-data 正式公開@pfrazee.com が「非公開グループ・コミュニティを可能にする大きなアップグレードになる」と評価。♡275・🔁56 |
| 07-08 | Blacksky が「Blacksky限定投稿」を公開。この件で最も反応の大きい投稿（♡511・🔁174・📝73）。ただしこの時点では独自実装であり公式仕様ではない |
| 07-17 | Diary 7: Off the Record（本編最終回）。パーミッションド・リポジトリの構造・署名・同期を扱う |
| 08-07 | @offline.arushibandi.com が「listSpaces は自分が書き込んだスペースしか返さない」と指摘 |
| 08-10 | Bulleted 公開。@ngerakines.me のアウトライナー。すべての箇条書きが自分のリポジトリのレコードになる。♡111 |
| 08-14 | @ngerakines.me が credential 発行の2軸（policy／appAccess）を解説。同日 @habitat.network が同期用 Go パッケージ sap を公開 |
| 08-15 | Blacksky が公式仕様へ移行 独自実装から1か月で permissioned spaces 仕様そのものを実装。♡144 |
| 08-18 | アルファ公開ブランチ / 改名の提示 ブランチ permissioned-data-alpha と PR #5423 が立つ。@dholms.at はこれを「alpha publishing branch」と説明した。マージすると alpha 版 npm パッケージが公開されるもので、ブランチ自体は4月から断続的に動いていたという。同日、改名の投稿 |
| 08-19 | @brookie.blog：レコードは軽くスペース外へ出しやすいが blob は重い。blob の可視性を導出にする案を提示（♡15） |
8月15日の Blacksky の投稿はこう述べている。
@rude1.blacksky.team ♡144 · 🔁29 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 投稿
決着していない4点 #
提案は公開済みで実装も動いているが、設計の中核に開いた問いが残っている。いずれも8月に入って提起され、まだ結論が出ていない。
1. 権威はリポジトリとスペースのどちらにあるか #
@chrisshank.com は「レコードが存在するとき、スペースがリポジトリより大きな権威を持つ」構造を問題視する。同じレコードを複数のスペースで共有しようとすると、現在の設計ではスペースごとに新規レコードを作る必要があり、オブジェクトの永続性が壊れる。レコードを「スペースによって認可される」ものと捉え直し、1つのレコードが0〜n個のスペースに属せるようにする案が出ている。
@bnewbold.net は懐疑的だ。「ライフサイクルを通じて同じ方法で参照・同期されるべきだとは思わない。共通のスキーマ／表現を持つことが主な利点だ」。長文での応答を予告している。
提起 08-17 → フォーラム移行 08-18 · Bluesky側の正式回答待ち
2. 追加されたスペースをどう知るか #
listSpaces は自分が書き込んだスペースしか返さない。誰かに招かれても、書き込むまで発見できない。@dholms.xyz はプロトコル層の通知機構を不要とする立場で、スパム防止とメンバーシップの曖昧さを理由に挙げ、アプリケーション層での解決を主張する。@sashankg.bsky.social は相互運用性を理由に反論し、スペースホスト側のエンドポイントを提案している。
提起 08-07（@offline.arushibandi.com）· 最終更新 08-12 · 対立したまま
3. 一度スペースに入れたデータを公開できない #
@iame.li（Eli Mallon）は「これを常時やる必要が出てきている」と述べる。現状の選択肢は、スペースの内と外で同じレコードを二度公開することだけだ。@bnewbold.net はここでも「長文の回答に値する」と応じ、対面での議論を提案している。
提起 08-17 · 回答保留
4. メンバー削除は失効ではない（仕様上の制約） #
スペースからメンバーを外しても、既に発行された credential は無効にならない。止まるのは将来の発行だけだ。@phi.zzstoatzz.io は付与の側にも同じ非対称があると指摘する。鍵を渡す行為は「締め出されなくなる」と「いつ帰宅したかを正確に知られる」の2つの記述を同時に真にする。
付与と失効は反対語に見えて、どちらも片側にずれている。
出典 @ngerakines.me 08-14「Space Access」· 設計上の既知の性質であり、バグではない
実装状況 #
| プロジェクト | 内容 | 状態 |
|---|---|---|
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.me08-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（要認証）で全文検索し、投稿から一次資料へ辿った。
取得の経路
- 全文検索 —
permissioned/atproto spacesを期間・言語別に。話者を事前に知らずに済む - スレッド展開 —
getPostThreadで論争のリプライ木を深さ8まで。改名投稿・失効・公開転換の3スレッド - 一次資料 — GitHub の提案本文と PR #5187／#5423、Discourse フォーラム、Diary シリーズ全9本
注意
日付はすべて UTC で揃えた。Bluesky の createdAt は UTC であり、日本時間で表示すると1日ずれる投稿がある。エンゲージメント数値は 2026-08-19 時点の取得値だ。
一次資料 #
- proposals 0016-permissioned-data
- atproto PR #5187 / PR #5423
- discourse.atmosphere.community
- Daniel's Leaflets（Diary シリーズ全9本）
引用した投稿は原文のまま。訳は付けていない。
- HTML 100%