// HACKER NEWS — CYBERSECURITY
ATProto spaces: A new extension to ATProto that enables non-public data
The biggest update to atproto since it first launched is available as an alpha that you can develop on, starting right now!
This project has been a long time coming, as evidenced by the many names it’s had (first private data, then permissioned data, briefly buckets, and now atproto spaces). From early chatter on the forum, to the first development diary back in February, to the full proposal, the design of the protocol has evolved through the feedback, contributions, and discussion of the ecosystem. This is a big undertaking, not just for the Blueksy team but for the entire Atmosphere.
Recall that, by design, all data stored on the protocol today is public — every post, every follow, every like, every block. All of this data is stored on a distributed network of servers anyone can host that gets collated and rebroadcast by a global firehose anyone can tap into. This makes it possible to build high-scale applications like Bluesky and Tangled on a network that’s locked open.
There are, of course, features and entire products that rely on data that isn’t public. Settings, private bookmarks, forums ranging from dozens to millions of members, and subscription-only publishing apps all require a data model that isn’t fully public.
Spaces, a new protocol primitive, provide a way to store and sync non-public data while retaining the advantages of atproto like portable identity, interoperable/remixable data, and permissionless participation.
Today, we’re making the alpha available with running code, published SDKs, a sample app, and even a hosted PDS you can create an account on and develop against. This is truly an alpha. There will be breaking changes, and you absolutely should not run production code against it.
You can think of an atproto space as a miniature atproto network that can be gated so that only certain people and applications are able to access the data published in it. It may sound a little “heavy-duty” to say each space is a mini-atproto, but spaces are actually very lightweight and low overhead. A space can have a single record in it with minimal overhead or scale up to a billion records.
Apart from the space itself, things should feel familiar. Users have DIDs. Users host their data in their repositories. Records are JSON and defined by Lexicons. Applications sync repos and build views of the data.
Access to a space is controlled by a space authority, which is just a DID like any other account (and in some cases actually is your account!). The space authority determines which other DIDs are allowed to access the space. Records live in per-space permissioned repos on the author’s PDS.
It’s important to remember that 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.