AT Protocol's new Spaces alpha can keep a post off the public firehose, but it cannot keep an authorized service from reading it. That distinction will determine which private social apps developers can safely build on the protocol. AT Protocol opened the alpha on August 20, adding running code, TypeScript packages, a sample app and a hosted test server to a network whose records have so far been public by design.
Spaces extends the protocol used by Bluesky with access-controlled repositories for drafts, bookmarks, subscriber posts, private forums and group conversations. The project calls this its largest protocol update since launch, though the release is deliberately unfinished. The official announcement warns that the implementation has not received a careful security review, test data may be deleted without warning, and schemas may change without clean migrations.
A boundary around records, not a sealed box
Public AT Protocol applications work from records that people publish to repositories on their personal data servers, or PDSes. Relays collect and rebroadcast those records so applications can assemble feeds and other views. Every post, follow, like and block on the protocol today is public, according to the Spaces announcement. That architecture makes public data portable and easy for another application to index, but it is a poor fit for a draft or a members-only discussion.
A Space creates an authorization and synchronization boundary around a set of records. Each Space has an authority, identified by a decentralized identifier, that decides which users and applications may enter. Authors still keep their own data: records live in a separate permissioned repository for each user and Space on that user's PDS. An application with access gathers those distributed repositories and builds the shared view, as the protocol proposal explains.
The word "private" needs care here. Space data is not end-to-end encrypted. PDS operators and applications admitted to a Space can read the records they handle, which permits server-side search, indexing, notifications and moderation. The proposal explicitly describes the feature as access control rather than confidentiality; an application could add encryption at another layer, but encryption is outside this protocol proposal.
That makes Spaces suitable for data hidden from the open network but available to selected services. A private forum whose members accept server-side moderation fits the model. A group sharing material that must remain unreadable to its host does not. The proposal's confidentiality limit means developers will need to state that difference in product language because users may reasonably interpret "private" as encrypted.
How a Space changes AT Protocol's plumbing
A public AT Protocol account has one public repository. Spaces adds one permissioned repository for each user-Space pair. Records remain JSON objects defined through Lexicons, and the author retains authority through a DID. The addressing scheme adds a fixed space segment and identifies both the Space authority and record author, according to the draft specification:
at://{spaceDid}/space/{spaceType}/{skey}/{authorDid}/{collection}/{rkey}
The authority can be the user's own DID for personal material such as bookmarks, or a dedicated DID for a shared community. A Space type defines the expected kind of records and supplies a readable name for OAuth consent screens. The protocol does not force every Space into one membership system; its required simplespace implementation supports explicit member lists, public admission and decisions delegated to a managing application, as detailed in the proposal.
Reading begins with the user's application requesting a short-lived delegation token from the user's PDS. The application exchanges that token with the Space authority for a credential, which is then presented to the hosts carrying repositories in that Space. The draft sets a default lifetime of 60 seconds for delegation tokens and two hours for Space credentials. Credentials are bound to an application-held key using DPoP, so a host that sees one cannot simply replay it elsewhere as a bearer token.
Permissioned data also bypasses the relay layer. Applications sync Space repositories directly from PDS hosts and can register for write notifications. The proposal's scaling section says the sync format is lighter than public repository sync and that one application can fetch a repository once, then serve its own users from that copy. The cost moves toward PDS hosts, which now answer authorized application sync requests directly instead of relying on a relay to distribute public records.
This model preserves distribution at the storage layer while accepting that an application may maintain a full working copy. A Space authority can stop issuing credentials to a member, and the baseline management API supports adding or removing members. Those controls block future authorized reads. They do not turn previously readable records into cryptographic secrets, which follows from the proposal's stated lack of confidentiality.
The sample app makes the boundary visible
AT Protocol published Bulletin as a small test of the design. Each user can create one board under their DID. Followers may read it, mutual followers may leave notes, and the owner can move or remove other people's notes, according to the Bulletin repository. The example is more informative than a generic private-message demo because separate rules govern reading, writing and administration.
Bulletin also shows the current cost of experimenting. It requires Node.js 22 or newer, pnpm and an account on a Spaces-compatible PDS. Its repository points developers to a special multi-PDS development network on the permissioned-data branch of the main AT Protocol codebase. The setup instructions make a useful reference implementation, but the dependency on alpha infrastructure keeps it firmly in developer territory.
For teams that do not want to run a server, AT Protocol is hosting an alpha PDS and distributing access through BPS accounts. Self-hosters can use the ghcr.io/bluesky-social/atproto:pds-spaces-alpha image with the reference PDS distribution and no new configuration. The announcement says the hosted service and SDK snapshots are scheduled for Thursday updates, so behavior can move underneath an experiment from week to week.
Several independent implementations are already testing the proposal: ZDS in Zig, two Rust PDS projects called atproto-crates and rsky, and the HappyView AppView framework. Their presence matters because interoperability is the test for a protocol proposal, while one working server only proves a single implementation. AT Protocol asks implementers to report places where the proposal and active reference branch disagree.
Moderation becomes admission-dependent
Public moderation services can observe public records and publish labels for applications or infrastructure providers to use. A moderator cannot inspect a Space unless its authority admits that service as a reader. The proposal recommends keeping labels for permissioned records inside the same Space, since a public label could reveal metadata about content that was meant to stay out of public view.
That choice gives a community control over who can inspect its conversations, but it also means independent moderation cannot assume network-wide visibility. The moderation design still lets PDS hosts remove accounts or refuse to serve repositories they host, while applications can filter their own views and individual authors can delete their records. Space authorities can refuse credentials to a user or stop issuing them for the Space.
Deletion has a similarly distributed character. When a Space is deleted, the proposal says the authority should notify registered syncers so they can discard their copies. Account deletion is also expected to propagate to downstream services holding public or permissioned data. These are protocol duties carried out by participating services, not remote erasure backed by encryption. Implementers will need to test how reliably those lifecycle events travel across multiple PDSes and application indexes.
An alpha with unusually clear stop signs
The release is ready for test data only. AT Protocol says its hosted PDS has no backups, may perform destructive migrations and will disappear when the alpha ends. It tells developers not to migrate real accounts, upload sensitive information or send ordinary users to the test server. The reference branch is under active development and may temporarily differ from published packages and the written proposal.
Those warnings narrow the immediate job. The alpha guidance leaves developers room to test whether multiple PDS implementations agree on repository sync, whether OAuth consent accurately describes a Space grant, and whether credential revocation behaves predictably across hosts. Production teams should wait for a security review and a migration path rather than treating the available Docker image as a release candidate.
AT Protocol aims to launch Spaces later in 2026 and plans to keep publishing alpha builds during the fall. The evidence to watch is less glamorous than another sample app: independent servers exchanging the same records, security findings resolved in public, stable schemas, and reliable deletion and membership changes across cached copies. Until those pieces settle, Spaces is a credible protocol experiment for non-public social data, with a privacy boundary that developers must describe precisely.