Protocol design for atproto spaces is wrapping up, and they are expected to roll out to the network by the end of November. There is still a list of open questions to work through, but the overall architecture has gotten a lot of review and is pretty firm.
What impact will this new functionality have on the network in the long run? How does it fit in with the public broadcast protocol? What does it mean for decentralization? Questions like this have been core to the protocol design process since the start, and there have been many public conversations about them. This post is an attempt to summarize my own personal analysis at this point in time, just before it gets ripped out of our hands.
Many of the design priorities and "theories of change" for atproto spaces are the same as public broadcast: credible exit, interoperation happens in the data, etc. In this post I'm going to focus on what is new and different.
Decentralization
Spaces will come in multiple forms, supporting personal data, public data, and limited-access group data. Of those broad patterns, I think the decentralization dynamics around limited-access group data are the most important to consider, and the most direct contrast with the radically public global broadcast that the current protocol supports. There are multiple new forces in play, some that could help devolve power down to smaller operators, and others that could push towards long-term consolidation.
One big decentralizing factor with spaces is that it is much easier to "scale down" operations to individual communities. This includes both indexing data (communities self-hosting their own app services) and taking care of moderation. It should be much easier for communities to "exit" from large providers if they don't need to index and moderate the full network. And easier to customize community experiences, including changing the "rules of the game" of application modalities. It may be hard to self-host every little detail: a lot of experiences involve supporting bits of public broadcast data here and there, and it is easiest to call out to big world indexing services for those. But overall I expect spaces to make a huge difference in how easy it feels to get started with meaningful independent operation.
As a force in the opposite direction, non-public data is by nature valuable and excludable, and that creates concerning incentives for service providers. Data is always valuable, but the easier it is for anybody to access it, the less competitive advantage there is for large players. The atproto public broadcast protocol is radically open and low-friction, which makes it hard for anybody to leverage or exploit public data. We lose that property with restricted access space data. Suddenly user data is scarce again, larger operators will have broader access and visibility than new entrants, and they might be able to leverage that to grow even larger. I'm particularly concerned that large providers might be able to provide better app product experiences because of their visibility into more data. One example of this is anti-abuse: similar to Gmail having vastly more spam to train on, the more behavior you can surveil, the easier it can be to detect patterns of abuse. Another is recommendation and discovery: the more closed communities you can peek inside, the better you can match-make for potential members, or learn to identify quality public content from private curation and discussion. I'm not sure what could be done to mitigate this at the protocol level, other than E2EE (which has its own trade-offs).
I think network effects are different for private groups than big world public networks. That doesn't mean they are weak: there are huge advantages to hosting groups somewhere popular with lots of overlap with other groups. But collective action is more feasible to organize at smaller granularity. For better or worse, a lot of people are still juggling five or six different messaging apps, year after year, because different groups have stuck to one or another.
The ability to gate access to data in a space based on the client_id could be abused to lock out competitors. Client apps set the default configuration, and defaults are powerful. And I usually want individuals to have the freedom to select their own software and user-agents. But in this case that freedom is in tension with the ability to exclude surveillance and bad actors. The client_id gating functionality is intended for privacy-sensitive use-cases like dating apps. At the end of the day, control rests in the space authority, not client apps. I am optimistic that enough folks will want to run alternative software (and bug their space authority for permission to do so) that reasonable norms and expectations will evolve over time.
A factor that currently feels like a bit of a toss up is privacy and security concerns around infrastructure operators (PDS, app services, etc) having access to non-public data. For some folks, this will be an incentive to avoid corporate providers and switch to smaller more values-aligned providers. On the other hand, other folks might prefer providers with better-funded security teams and impersonal professional operations. Would you rather trust a small community provider you have personal relationships with? Or is that exactly who you would be least comfortable having access to your private data? Maybe the best will be mid-sized privacy-forward hosts offering paid hosting.
How do all these factors balance out? Over long timescales other factors might come into play, but I'm pretty confident that the "scale down" functionality will be a decentralizing force in the near term.
Moderation
After many rounds of debate, our theory for moderation in the public broadcast protocol was that it should be composable, not tied to any specific piece of infrastructure, and that responsibility for moderation centers around branded apps. In that analysis, network services like the PDS and relay have a more limited role to play, similar to the type of infrastructure moderation that cloud server hosts and transit providers engage in.
What is the story with spaces? Does all the responsibility fall on the space authority?
I think it's going to be a split. Space authorities will be in the best position to do "high-context" moderation within groups and communities. But there are some patterns of abuse (botnets, spam, brigading) which hit networks at scale, and communities aren't going to be well equipped to handle internally. I think branded apps will still have a large role to play in "baseline" moderation.
Hosting
Spaces will impact the trust relationship between accounts and their hosting provider (PDS or group host), as well as the operational security risk model for hosting operators.
Account hosting already requires trust in the infrastructure provider. They usually control the current atproto keys for the account and could in theory manipulate repository data or make requests elsewhere in the network. It would be great to get more accounts in control of their long-term network identity, but today hosts usually control that as well. But most data in the network today is public. Spaces mean that hosting providers will have access to restricted data. Operators might snoop around, or even share data with third parties. Regulation and privacy policies may impose legal barriers to abuse, but there is still a new trust dynamic in play, especially with casual friends-and-family hosting arrangements.
For hosting providers, having even hypothetical access to restricted data can change the operational risk profile. They might be subject to more law enforcement data requests, or be a bigger target for hackers. Infrastructure-level moderation also becomes more complex. With public broadcast data, large service providers can observe the full-network firehose for abuse, and it is simple enough for anybody to fetch public data to confirm content or behavioral issues. With restricted data, this is no longer possible, and hosting providers are a bit more "in the dark". The "abuse notices" proposal could help with this.
Hosting already involves trust and operational care, and space data is expected to be less sensitive than personal messaging (use E2EE systems like Signal and Germ for that!). And the situation doesn't change much for individual self-hosters or for larger operators like Blacksky, Eurosky, and Northsky. So I'm not sure how big of an overall change this will be.
Replacing or Complementing Existing Protocol
Which use-cases are more appropriate for spaces versus the existing public broadcast protocol? Does public data become a special case of permissioned data? How should developers think about this?
It is tempting to contrast the two protocol mechanisms as being all about access control: "public" versus "permissioned". And there is some truth to that: if you need non-public data, you gotta use spaces. But as we've mulled things over and gotten more comfortable with using spaces for public data as well, the distinction has come to be more about "locality" than access control.
Imagine a line going from "local/contextual" on one end to "global broadcast" on the other. The two protocol mechanisms cover different spans of that spectrum, with a big overlap in the middle. Applications often have multiple product features that each end up at different points along the spectrum. I think that there will be many situations where either of the mechanisms could be justified, and developers will need to make an opinionated decision. And that many apps will implement both sync mechanisms to support different product features.
For example, public Reddit-style topical discussion forums could technically be implemented with either mechanism. I myself would still consider public broadcast for that modality, though I know that thinks that spaces would be the natural choice.
Our consensus within the Bluesky protocol team is that we should not hamstring either of the protocol mechanisms just to prop up the other. There are proposals floating around to make spaces work better for global broadcast, such as redistributable cryptographic commitments, or publishing space data over the firehose. These would be big changes, and I do not think they are going to ship in spaces this year. But it is important to clarify that the reason they won't is not to artificially limit the usefulness of spaces, or to protect the public broadcast protocol from cannibalization. We should remain open to expanding the scope of atproto spaces over time.
I do think that the public broadcast protocol has some important properties and affordances for scaling up "big world" modalities, and that if spaces are to extend all the way to that end of the spectrum they will look more and more like the public broadcast protocol.
One of the changes with spaces is that the space type explicitly declares the "modality" of data, distinct from record schemas. This provides additional context about "why" a piece of data is being published and how it might be integrated and displayed, beyond just what format the data itself has. In a lot of ways this contextualization is a welcome improvement! But I wonder what the impact will be on generic data reuse. One of the things I like a lot about the "open web" is that data can get picked up and reused/remixed in unexpected and permissionless ways. This can certainly go wrong ("decontextualization"), but there can also be a lot of joy and serendipity to it. Generic infrastructure like microcosm is really cool and allows all sorts of unexpected discovery and interlinking. Apart from the complexity of access control, there is nothing about spaces that technically prevents generic data reuse. But I think it is subtly likely that integrations and reuse across modalities could be more limited and intentional than with broadcast data. This could be a net positive, or a vibe shift, or maybe doesn't change much at all.
Spaces make it possible to build non-public social app experiences, which are increasingly popular. Will we all flee from the public web to cozy spaces? This topic is probably worth a separate post, but my personal interest with atproto remains breaking the platform network effects around public conversation. That still matters even if fewer folks overall participate publicly and most social interactions online continue to move into closed groups. I think new non-public product features will complement public ones, and help the atmosphere succeed as a whole.
Beyond Horseless Carriages
Historical context has had a pretty big influence on what applications and product experiences have been built on atproto. Bluesky was the flagship app, developed by the same people at the same time as the protocol, and it is a famously faithful reimplementation of the Twitter microblogging experience. The decision to build a "horseless carriage" (as Rudy Fraser put it) instead of a novel experience was a hard one, and I expect will continue to be reassessed and relitigated for years to come. Among other considerations, it felt important at the time to demonstrate that a relatively polished substitute was possible, with "no steps back" compared to a familiar big-world platform experience.
I think the story is going to be pretty different for experiences built on atproto spaces. Part of this is that there is an ecosystem right from the start: folks have been building before protocol design work even started in earnest. This time around has been more of a "protocol/ecosystem" design process, in contrast to "protocol/product". Part of it is that folks are rightfully impatient with rote re-implementation and want to experiment and differentiate more. Coding agents are making it much easier to prototype and experiment with new ideas, making it less risky to try something new, or to build weird and bespoke experiences for individual communities. Another difference, at least for Bluesky, is that there isn't an obviously successful group product feature to plop in, as there was for video, DMs, etc. There have been several attempts to integrate groups into microblogging with mixed success, and novel product thinking will be required to make it successful.
And a big thing is that I think the "atmospheric groups" concept is just a new thing under the sun, and is going to feel different once people try it out. This is the functionality where you can participate in multiple different app modalities, and your groups are shared between them. And then you can build a home for just one group that pulls together data and context from all those different modalities in one place. I think there are a lot of new things to try with this, it is going to be pretty exciting for designers and users alike, and it is going to differentiate the atmosphere more clearly from what came before.