Bluesky releases atproto spaces alpha for non-public data

Bluesky releases atproto spaces alpha for non-public data

Bluesky released an alpha of atproto spaces, described as the biggest update to the atproto protocol since it launched. Until now, everything stored on atproto has been public by design: every post, follow, like and block sits on a distributed network of servers that anyone can host, collated and rebroadcast by a global firehose anyone can tap into. That openness is what makes high-scale apps like Bluesky and Tangled possible, but it leaves no room for features that need to stay private, such as settings, private bookmarks, forums, or subscription-only publishing. Spaces are meant to fill that gap.

A space works like a miniature atproto network that can be gated so only approved people and applications can read its data. It can hold as little as a single record with minimal overhead, or scale up to a billion records. Outside the space itself, the mechanics stay familiar: users still have DIDs, still host data in their own repositories, and records are still JSON defined by Lexicons. Access is controlled by a space authority, a DID (sometimes the user's own account) that decides which other DIDs may access the space; records live in per-space permissioned repositories on the author's PDS. The team is explicit that spaces provide access control, not confidentiality: data inside a space is readable by anyone with access to it and is not encrypted. Because spaces are not rebroadcast through a relay the way public data is, their sync protocol is lighter weight and built for real-time sync, with applications syncing directly from PDS hosts instead.

The intended range of uses spans from single-member spaces holding settings or drafts, through gated content such as subscription-only publications, up to shared social spaces the team expects could grow into communities of millions of participants; forums ranging from dozens to millions of members are cited as an example of the kind of non-public data model the feature is meant to support.

For testing, Bluesky is running a hosted PDS that developers can get an invite code for through their BPS account, updated on a planned weekly cadence (Thursdays). The hosted instance is explicitly a shared sandbox: it carries no backups, may go through destructive data migrations with no recovery path, and will be deleted entirely once the alpha period ends, so nobody should point non-developer users at it or upload content they are not willing to lose. Developers who want to self-host instead can pull a tagged Docker image, ghcr.io/bluesky-social/atproto:pds-spaces-alpha, compatible with the reference PDS distribution and requiring no new configuration. The TypeScript @atproto packages were also released as alpha snapshot versions installable under an alpha tag.

Bluesky points to a sample app, a bulletin board at bulletin.my (source on GitHub) that lets a user's mutuals leave sticky notes visible only to that user's followers, built on top of a space. It also lists four community projects already implementing the proposed spec ahead of the alpha: ZDS, a PDS written in Zig; atproto-crates PDS, a Rust implementation; rsky PDS, another Rust PDS maintained by Blacksky; and HappyView, an AppView framework. The protocol specification lives in the proposals repository and the reference implementation on the atproto spaces branch of the atproto repo, which the team says may temporarily diverge from what is actually published.

Bluesky frames this squarely as alpha software: the code has not had a careful security review, so no sensitive information should be uploaded, and the protocol design, SDKs and database schema are all expected to change, with no guarantee of clean upgrades between versions. The team plans to keep iterating through the fall, with a goal, not a firm date, of a full launch later this year.

Key facts

  • Bluesky released an alpha of atproto spaces, a new protocol primitive for storing and syncing non-public data on atproto, which until now stored everything publicly by design.
  • A space can hold anywhere from a single record with minimal overhead up to a billion records, and access is gated by a space authority (a DID) rather than encryption; data in a space is readable by anyone granted access.
  • The alpha ships with a hosted PDS (invite via BPS account, updated Thursdays), a self-hostable Docker image (ghcr.io/bluesky-social/atproto:pds-spaces-alpha), alpha-tagged TypeScript @atproto packages, and a sample bulletin-board app at bulletin.my.
  • Four community projects already implement the proposed spec: ZDS (Zig), atproto-crates PDS and rsky PDS (both Rust, the latter maintained by Blacksky), and the HappyView AppView framework.
  • The hosted alpha PDS has no backups, may undergo destructive migrations with no recovery path, and will be deleted entirely once the alpha ends; Bluesky's stated goal is a full launch later this year, not a committed date.

Why it matters

Atproto's core design bet has been full public openness: every post, like and follow sits on servers anyone can host and rebroadcasts through a public firehose anyone can tap. That openness enabled Bluesky and other apps to scale, but it structurally excludes anything that needs to stay private. Spaces are Bluesky's answer to that gap: a way to keep atproto's portable identity, interoperable data and permissionless participation while adding a place for data that should not be world-readable. Bluesky calls it the biggest update to the protocol since launch, and says the effort spans not just its own team but the wider Atmosphere ecosystem, which is echoed by four outside projects already building against the draft spec before the alpha even shipped.

Who it affects

Developers building on atproto gain a new primitive for features that were previously impossible on the network: private settings and bookmarks, gated or subscription publishing, and closed forums or communities, which the announcement says could scale to millions of participants. PDS implementers and ecosystem projects, such as the Zig-based ZDS, the two Rust PDS implementations (atproto-crates PDS and Blacksky's rsky PDS), and the HappyView AppView framework, are directly affected as they align with the evolving spec. End users are affected only indirectly for now: Bluesky explicitly warns developers not to point non-developer users at the alpha PDS.

How to use it

Developers can start against the hosted alpha PDS by getting an invite code through their BPS account; it is updated on a planned weekly cadence, Thursdays. Those who want to run their own server can pull the tagged Docker image ghcr.io/bluesky-social/atproto:pds-spaces-alpha, which is compatible with the reference PDS distribution and needs no new configuration. The TypeScript @atproto packages are available as alpha snapshot versions installable under an alpha tag, and the sample bulletin-board app at bulletin.my ships with its source on GitHub for anyone to run locally, fork or remix. The protocol specification sits in the proposals repository, and the reference implementation lives on the atproto spaces branch of the atproto repo, which the team says may diverge from what is actually published while it is under active development. No pricing or resource-usage figures are given for running a spaces-capable PDS.

How solid is it

This is explicitly alpha software, not a finished feature. Bluesky states plainly that breaking changes will happen and that production code absolutely should not run against it; database schemas may change without clean migrations, and there is no guarantee of a clean upgrade path between versions. Four outside projects already implementing the draft spec, plus a working hosted PDS, sample app and released SDKs, indicate the design has moved past a pure proposal stage, but the team itself frames a full launch later this year as a goal, not a commitment.

Risks and caveats

Bluesky is direct that spaces provide access control, not confidentiality: data inside a space is not encrypted and is fully readable by any user or application granted access to it, so it should not be treated as a secure or private storage mechanism in a cryptographic sense. The code has not undergone a careful security review, and the team explicitly warns against uploading sensitive information, one's own or anyone else's. The hosted alpha PDS carries no backups, may go through destructive data migrations with no recovery path, and will be deleted in full once the alpha period ends, so any data placed on it should be treated as disposable.

“spaces give you access control not confidentiality. The data in a space is readable by any user or application with access to that space, it's not encrypted.”

— atproto spaces alpha announcement