The movement of using open protocols to build independent social networks can be framed in different time periods, depending on what you’re tracking. You can do this by focusing on user behaviour, such as the move towards Mastodon after Elon Musk took over Twitter, or the inflow of users towards Bluesky after Trump won the 2024 election. But you can also do this by focusing on what platforms and products people are building on atproto and ActivityPub. And here, for a long time, the dominant mental model has been Twitter-like microblogging platform. For the fediverse this understanding was set by Mastodon, and even when other platforms like Lemmy got attention in 2023, the dominant understanding of the fediverse was that of being a network for microblogging. For Bluesky and the atmosphere this understanding of being a microblogging network is even stronger, with virtually all of its users engaging with the Bluesky app as a microblogging platform, with only a small group of people using the network to build a wide variety of other types of social experiences.
On the development side of the open social web there now seems to be a shift however, away from building Twitter-like platforms, towards private data and closed communities. Part of that is that the growth for alternative microblogging platforms has stalled, and the monthly active users for both Mastodon and Bluesky have declined over the last year. This in itself is part of a larger trend, where both X and Threads either struggle to grow or are even losing users.
The atmosphere is in the middle of a lively debate about how private data should work, with multiple projects developing different proposals that disagree on basic questions about where data should live, who controls access, and what the relationship between protocol and application should be.
Bluesky PBC has been working on permissioned data for a while, and in their roadmap for spring 2026 they describe permissioned data as their ‘major focus’. In the post they note that the details are still an open question, referring to other teams working on comparable implementations in parallel. In a series of blog posts, Bluesky engineer Daniel Holmgren has been working through Bluesky’s proposal, which he calls permission spaces. These spaces have shared social contexts with perimeters, partitioned across the PDSes of their members, with their own DIDs to allow ownership transfer between users. As work progresses it has become clearer that Bluesky’s proposal functions as a parallel protocol to atprotocol, with Holmgren writing: “At the end of the day, specifying a new protocol scheme is basically owning up to the fact that, while we may re-use many primitives and roles from the public data protocol, we are specifying a new data and sync protocol, not just an extension to the existing protocol.”
Blacksky’s Acorn arrives in a fairly similar architectural territory, but argued from the opposite direction from Bluesky. Where Holmgren is reasoning from how private data should work on atproto, Blacksky has been reasoning from what infrastructure the Black community on Bluesky needs to grow and stay safe. With Acorn, Blacksky has created a community infrastructure platform, that offers a modular service stack (custom feeds, badges, custom clients, governance pipelines, dedicated PDSes) that communities can grow into as their needs evolve. Blacksky is also working on Blacksky-online posts, which function as a form of permissioned data. Blacksky founder Rudy Fraser has regularly pointed out that ‘community is the only moat’, and software like Acorn and Blacksky’s private data are ways to build and sustain the communities.
Several other projects are working on overlapping problems from different angles. The developers behind Habitat are specifically building towards private/permissioned data at the organisational or group level, and they challenge the premise that apps need to see the data in the first place, arguing for a more PDS-centric local-first approach. Evelyn Osman’s Stratos, built for Northsky, takes a third path with protocol-adjacent services that provide domains and boundaries for private data without requiring changes to the PDS. Zicklag’s Arbiter, built for Roomy, sits on top of Bluesky’s permissioned data proposal and adds role-based access control and federation-of-communities functionality.
The ActivityPub side is converging on the same problem through a coordinated institutional pathway. In December 2025, the Social Web Foundation announced that the Sovereign Tech Fund had commissioned two interoperable implementations of E2EE over ActivityPub. The two projects are Bonfire and Bandwagon, and at the recent FediForum developer Ben Pate showed a demo of this implementation working. In April 2026, Mastodon followed with its own €614K agreement from the Sovereign Tech Fund, with implementing the ActivityPub E2EE extensions as one of five major deliverables, on the timeline of 2027 once the W3C task force specification is finalized and interoperability between Emissary and Bonfire has been demonstrated. Meanwhile, Lemmy’s headline feature for their upcoming 1.0 release is the addition of private communities, where only approved followers can view the content.
Both ATProto and ActivityPub, two protocols designed around public-by-default architectures, are now devoting substantial development effort to retrofitting private and bounded-community functionality into their stacks. The public-by-default architectural choice that defined the current generation of open social networking protocols is now getting more recognition that, while being valuable and useful, this also not enough. Private and bounded interaction is increasingly understood as at least as important as public broadcast.
This is in itself already an interesting finding: there seems to be shift within the open social web, from being focused on public broadcasting, to seeing a wide variety of work in the direction of private and bounded places pop up. But there’s even more to it.
Squint a bit at these proposals and projects above, at the idea of using open protocols to transfer private/encrypted data, with the main focus point being a private ‘space’ instead of a public feed, and things start to look suspiciously Matrix-shaped.
What do I mean with Matrix-shaped?
Matrix is another open networking protocol, around for over a decade. It’s mostly associated with end-to-end encryption, with apps like Element built on top to let users send fully encrypted messages, which makes Matrix frequently compared with apps like Signal. This framing isn’t wrong, exactly, but it puts the emphasis in the wrong place. The encryption is important, but what makes Matrix architecturally distinct from other encrypted messengers is the room, not encryption.
In Matrix, the room is the central object that contains all the relevant information. It knows who has access to the room and what the room is about. Messages are content flowing through the room, with the room itself as persistent shared state that exists across the servers of its members. When you send a message in a Matrix room, you’re not really delivering it to anyone. You’re adding to the shared state of the room, and that addition gets replicated to every server that hosts a member of the room. End-to-end encryption, when a room uses it, encrypts the content of messages, but the room itself and its membership are established at a layer underneath the encryption.
This is what bounded community spaces actually need, once you decide to build them. A space needs to exist somewhere, have a method to define membership, and be able to make and enforce rules for what members can do in the space. These are fairly generic requirements that are not specific to any protocol. Different protocols can and do implement specific pieces in different ways, but the basic shape is roughly the same.
Look back at the atproto and ActivityPub projects mentioned above. Bluesky’s permission spaces have boundaries, explicit members, and stable identities through their own DIDs that let spaces survive changes in who owns them. The data is partitioned across the PDSes of the members. Acorn’s relationship graph tracks who someone is to a community across atproto’s separate services like custom feeds, badges, and moderation labels, doing work that’s analogous to what Matrix room state does within a single room, but spread across Blacksky’s community stack. The MLS-based work on the ActivityPub side gives groups explicit membership, with encryption keys that rotate as members join and leave. While the technology, terminology and specific implementations are different, the basic shape is the same: a bounded space with members and rules, with the state of the space replicated across the infrastructure of the people in it.
What’s so interesting about this convergence to me is that the reasoning paths are very different, while ending in roughly the same place. Bluesky is trying to solve “how should private data work on atproto.” Blacksky is trying to solve “what does the Black community on Bluesky need to grow and have a safe place. ” The Mastodon team is trying to solve “how do we add private messaging to ActivityPub.” Each ends up with bounded spaces, explicit membership, persistent state, and access decisions at the boundary. This is roughly the same shape as what Matrix has been building. Bascially, it seems to me that we’re doing carcinization for protocols.
So this is the second interesting finding here: the private data proposals from the atproto and ActivityPub communities share a significant conceptual overlap with Matrix’s rooms, even as the underlying technical specifications might differ significantly.
But from here, things get stranger:
Matrix has spent the past several years pivoting hard toward institutional and government customers. At the Matrix Conference in Strasbourg in October 2025, Matthew Hodgson committed publicly that Matrix would “laser-focus on being the best decentralized secure comms platform in the world,” and that “decentralized social” would not be pursued.
So this leads to a very strange observation: decentralised open social networking protocols seem to be converging towards private messaging in bounded spaces, while the protocol that already does private messaging in bounded spaces is explicitly pivoting away from decentralised social networking.
Why is this? Why has an integration between Matrix and atproto or ActivityPub never really caught on? What made Matrix decide to pivot away from decentralised social networks towards government institutions instead?
These questions sit inside a larger institutional moment. At 2mr.social in Hamburg in early May 2026, a coalition of fediverse and atmosphere operators presented a declaration formalizing the three-protocol framing as the operative position for the European open social web. The Hamburg Declaration positions Matrix, the fediverse, and atproto as complementary parts of a European stack, with explicit cooperation areas including a European-hosted Euro Bridge, shared moderation tooling, and joint funding. The declaration shows that understanding what the European open social stack can become requires understanding Matrix, both as a protocol with a specific architecture as well as an institutional actor that has its own culture, politics and governance.
Matrix is being adopted by European governments who want digital sovereignty from American platforms, with deployments in French and German government institutions, and the European Commission is also starting a pilot to use Matrix. France’s DINUM became the first country to formally pay into the Matrix Foundation. But the financial reality of that adoption is more precarious than the success story suggests. The Matrix Foundation reported in early 2025 that it needed $100,000 by the end of March to keep its bridges running, with $1.2M in annual operating costs against $561K in incoming revenue. Element, the main commercial entity behind Matrix, pivoted to government implementations because the post-COVID funding environment made the experimental phase unsustainable. So while the European governments highly prioritise digital sovereignty in their talk, getting European sovereign tech funded remains a massive challenge, even as the sums of money are small in absolute terms.
This all is happening in a context where European regulations for open social networking protocols are, well, not particularly coherent, let’s say. The Digital Markets Act wants messaging interoperability, but also does its absolute best to ignore Matrix and what is actually happening in the space. A ruling by the Court of Justice of the European Union (see my recent article on this) creates compliance problems for public-by-default federation that the bounded community architectures we’ve been tracing here partly sidestep. So while social networks that are not dependent on US Big Tech platforms have salience in Europe, and Matrix is seeing institutional adoption, the political landscape is far from coherent.
The reason I write Connected Places is because I think open social networking protocols will drastically shape the next phase of how we as a society communicate online. This is, quite frankly, fucking terrifying. Big Tech has shown that social platforms fundamentally shapes how our politics, our society and our culture function. Therefore I think it is important to understand how these new open social protocols actually function in practice, in a way that goes beyond a surface-level hype. That’s why my next project is to write a series of articles about Matrix. What’s actually happening here, what are people building, how are people using Matrix, and how does protocol governance work for Matrix. As ActivityPub and atproto work towards implementing permissioned data in various formats, I want to know what’s happening with the protocol that’s been doing that for over a decade.
