As someone reading this from the periphery (and not really even as I have been in the ecosystem, building etc), my first thought was this was some kind of live audio conversation thing ala Twitter Spaces. But nope. I know I know, you want to do your own thing, define your own naming, but alot of people still view things as far as Bluesky's relation to Twitter, in the consumer lens. You'll get there as far as independent separation but it's not there yet (similarly, Bluesky & atproto's connection/independence).
And this isn't even a consumer thing in this respect, but a dev/protocol thing.... couldn't have gone with something like Zones... Permissioned Zones?
Collins: "A particular kind of space is the area that is available for a particular activity or for putting a particular kind of thing in."
Cambridge: "an empty area that is available to be used"
why do you think Twitter called them spaces in the first place?
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.
Spaces are a very flexible primitive, and the range of uses is deliberately broad. The smallest spaces will contain exactly one member and are useful for storing data like settings, drafts, bookmarks and other private data that an app might want to store. Spaces work for gated content as well, such as a publisher that wants to distribute a subscription-only publication. Where spaces really shine, and in some sense what they were designed for, is establishing a shared social context. In this capacity, the largest spaces will be communities that may grow to millions of participants.
The sync protocol for space data is significantly lighter-weight and provides facilities for real-time sync. This is because, unlike the public broadcast protocol, there is no concept of a relay for data stored in a space. For public data, the relay helps provide applications access to all of the data across the network. However for spaces, it’s often not desirable to rebroadcast content. Applications will sync space data directly from PDS hosts.
If you want to test out the protocol without running any infrastructure, you’re in luck! We’re hosting one for you and will keep it up to date with the latest changes.
Head over to your BPS account for an invite code and a link to the alpha PDS.
This is a shared sandbox and we intend to keep it usable. If you cause moderation problems, engage in unproductive abuse of the network, or otherwise try to use the PDS for purposes other than experimenting with spaces, you will be permanently banned from the alpha.
You should also expect the data stored in the PDS is neither permanent nor stable. The data model will change, we may even delete everything without warning. The PDS as a whole will be deleted after the alpha.
We plan to update the hosted PDS and SDKs on Thursdays. We’ll post changes to the announcements thread on atmosphere.community, please subscribe.
If you want to run your own PDS, we’ll maintain a tagged Docker image at ghcr.io/bluesky-social/atproto:pds-spaces-alpha with support for spaces. This image is compatible with the reference PDS distribution and does not require any new configuration.
THIS IS ALPHA SOFTWARE DO NOT USE IT IN PRODUCTION. Breaking changes will happen and database schemas may change without clean migrations. We strongly recommend that you do not migrate your real accounts to this version. Do not expect that you’ll even be able to cleanly upgrade between versions.
That said, do please use the new PDS with test data. Explore spaces and the kinds of applications you can build with them. Report bugs, let us know if you were expecting something to work one way and it turns out to work differently.
We’ve already seen a few ecosystem projects that have begun to implement the proposed spec:
Real protocols have many interoperating implementations, and it’s been amazing to see the ecosystem lead the way on this.
There’s an example app running at https://bulletin.my. This app lets you host a bulletin board (as a space!) that your mutuals can leave sticky notes on. Only your followers can see your board. The code is available https://github.com/bluesky-social/bulletin. Give it a run locally, or fork it and remix it into something new! If you have your own PDS implementation, try logging in and seeing if everything works as expected.
To support this, we released the TypeScript @atproto packages as alpha snapshot versions. These can be installed with the alpha tag. Check out the bulletin repo to see them in action.
If you want to dive deeper into the protocol, the latest version of the protocol specification can be found in the proposals repo. If you’re working on your own implementation of atproto spaces, this is the thing to collaborate around. We’ll keep the proposal up to date with the current reference implementation. If you find ambiguities or places where the implementation and proposal diverge, please open an issue.
The reference implementation can be found on the atproto spaces branch of the atproto repo. This branch is being actively developed and may temporarily diverge from the packages and PDS that are published.
As has already been mentioned several times, expect changes as we continue to develop the code. Specifically, this means:
We will continue to iterate and build tooling throughout the fall, with a goal of launching later this year. Follow the announcement post in the Atmosphere Community forum for updates on new builds, which we plan to drop on Thursdays.
Feel free to start building apps with test, non-production data against the hosted PDS. Or host your own PDS—either the reference implementation or one of the community-managed ones. Run the sample app or build your own. Report issues where you find them.
We are excited about the entire new class of applications atproto spaces enables and for developers to get their hands on the code.