Shared non-public application state raises four separate questions: who owns each record, which identity controls access, how applications interpret the data, and how authorized participants receive updates. ATProto already supplies identity, repositories, and schemas. The Spaces alpha changes who may see a selected body of records and how those records move between hosts and applications. Read alongside the repository specification and Lexicon specification, it sketches an application substrate rather than merely a private-post feature.
Spaces add permissioned, per-space repositories and direct sync to ATProto's identity and schema machinery, but the current release is explicitly alpha infrastructure.
What a space contains
Before Spaces, the protocol's stored data was public and rebroadcast through a relay-based firehose. That model works when applications are expected to discover and process public records. Settings, private bookmarks, gated publishing, and member forums require a narrower audience.
The project describes a space as a lightweight, miniature ATProto network whose data is available only to selected people and applications. A space may contain one record or, according to the project's stated design range, as many as a billion records.
The surrounding objects remain familiar. A DID is the identifier used for a user or authority. A Personal Data Server, or PDS, hosts repositories. Users place records in repositories on their PDS hosts, records are JSON objects defined by Lexicons, and applications synchronize repositories to construct their own views of the data.
Each space has a space authority, itself represented by a DID. That authority determines which other DIDs may access the space. Records live in per-space permissioned repositories on their authors' PDS hosts. The authority may control membership without becoming the storage location for every member's records.
A space can be modeled as a shared authorization context over individually hosted records. This architectural inference differs from treating the space as one central group database. A prototype should preserve that distinction in its internal model: space identity, authority identity, author identity, repository location, and application identity are separate fields even when a small demonstration happens to assign several roles to one account.
What repositories contribute
The established public records and provenance model explains why repositories are more than JSON document buckets. The repository specification defines an account repository as a key-value mapping whose paths have the form collection/record-key. Its contents are arranged in a deterministic, content-addressed Merkle Search Tree. Creating, updating, or deleting a record changes the repository root hash.
Each published public-repository state is represented by a cryptographically signed commit that points to the repository tree. The account's DID document supplies the public-key information needed for verification, and the authoritative PDS location is declared in that DID document. Complete public repositories can also be exported as content-addressed archive files for synchronization, backup, or migration.
The Spaces announcement says users still host data in repositories, but the available sources do not specify whether every public-repository export, proof, and binary-format behavior applies unchanged to per-space repositories. A prototype should verify that behavior against the alpha implementation instead of silently importing the entire public-repository contract.
The sources leave one scale caveat unresolved. The alpha post says a space can scale to a billion records, while the repository specification says individual repositories are intended for up to single-digit millions of records. The available sources do not explain how those two limits interact. Space scale and repository scale should therefore be treated as separate, unverified dimensions during alpha testing. One plausible reading is that a large space aggregates records distributed across many author repositories, but that is an inference rather than a stated guarantee.
Access, confidentiality, and application authority
Spaces provide access control without confidentiality. The alpha documentation says space data is not encrypted and is readable by every user or application that has access. The authority decides which DIDs enter the access set; the protocol described here does not conceal each record from other authorized members.
This architecture splits custody from governance: authors retain records on their PDS hosts, while the space authority governs admission to the shared context. That separation creates questions a prototype should make observable. Which DID authorized a reader? Which authority decision was current when a record was fetched? What happens to an application's local view after access changes? The available sources do not specify how already-synchronized copies are handled after revocation.
Access to records also leaves a broader application-authority question. Membership in a space identifies who may access its data. It does not, in the supplied description, fully specify every write, API, or external-effect permission an application might need. This is where the separate problem of agent authority and effects becomes useful: visibility into a shared repository should be represented independently from permission to mutate records or act elsewhere.
Lexicons define the shared language
Lexicon version 1 is a schema definition language for ATProto records, HTTP endpoints, event-stream messages, and permission sets. A Lexicon is a JSON file associated with a namespaced identifier, or NSID. Its primary definitions can describe repository records, HTTP queries and procedures, event subscriptions, or bundles of OAuth permissions.
For a record, the Lexicon declares the allowed record-key scheme and an object schema for the stored value. This gives independently implemented applications a common description of fields and types. The same language can describe an HTTP procedure's input and output or the messages carried by an event stream, reducing the temptation to hide the application's real contract in one client implementation.
Lexicon permission sets are bundles of permissions intended for OAuth scopes. The specification includes an important fail-closed parsing rule: permission declarations containing unsupported resource types or parameters must be ignored by access-control services. Unknown fields may narrow a grant, so accepting the recognized portion could accidentally broaden it.
The available sources describe space membership and Lexicon permission sets separately. The former is controlled by a space authority over DIDs; the latter describes OAuth permissions. A safe prototype should model these as separate layers until the alpha design proves otherwise.
Direct synchronization changes the application shape
Public ATProto data can be aggregated and rebroadcast by relays. Space data has no relay in the announced design. Applications synchronize it directly from PDS hosts using a lighter-weight protocol with facilities for real-time updates.
A space-aware application will likely need to track the relevant identities and PDS hosts instead of consuming one global stream. Since an account's current PDS location is declared in its DID document, host discovery and identity resolution belong near the start of the synchronization path. This is an implementation inference; the sources do not provide enough detail to prescribe the exact alpha algorithm.
A useful synchronization prototype should answer concrete questions:
- How does the application discover the repositories participating in one space?
- How does it obtain an initial view and then receive incremental changes?
- What changes when a member, application, or authority DID is added or removed?
- Can the application rebuild its derived view from repository data after losing local state?
- Which repository revision, authority decision, and schema version produced each displayed result?
These questions turn “real-time direct sync” into observable behavior instead of an architectural label.
Prototyping within the alpha
The announcement reports running reference code, alpha-tagged TypeScript packages, a sample bulletin-board application, a hosted experimental PDS, and a tagged container image for operating a Spaces-capable PDS. Those are reported alpha artifacts, not evidence of production readiness or broad interoperability.
The project's explicit guidance is unusually blunt: the code has not undergone careful security review, sensitive information should not be uploaded, backups are not provided, destructive migrations may occur, and the hosted alpha PDS may delete data without warning before being removed at the end of the alpha. Protocol details, SDKs, and database schemas may change, potentially without clean upgrades.
Prototype with synthetic, disposable records and aim to falsify architectural assumptions. Use at least one authority DID, multiple author DIDs, and a distinct application identity. Define one small Lexicon record, write it from more than one author, inspect where each record resides, synchronize it into an application view, and exercise membership changes. Record the implementation and schema versions alongside every result.
The useful output is an assumption ledger: which identity owned each object, which DID granted access, which PDS served it, which Lexicon definition described it, which implementation and version validated it, which revision the application observed, and which behavior came from the specification versus the current alpha implementation.