loading . . . **Where Does Community Live?**
Whatβs always interested me about Ostromβs work is that she showed how governance of communities is very diverse, with rules that look chaotic on the surface but share deep structure underneath. Whatβs more, her understanding of how communities self-organize and govern themselves is relevant to the social web today. Across the open social web there are new types of communities being built, and people actively experimenting with how governance works in these communities.
At the Eurosky conference in Berlin in November 2025, technologist Robin Berjon made a statement that referenced Ostrom, and tied to protocols: βThe properties that define the architecture of a protocol and those that define the rules in an institution are the same.β I think thatβs largely true, but I also think we can be even more specific.
The open social web today consists primarily of two protocols, ActivityPub and ATProto, each with very different ideas about how to organize social life online. Neither prescribes a single network topology, and both leave fundamental choices about how social space should be structured to the people building on top of them. But their architectural decisions are not neutral: they shape and constrain the topologies that can emerge, the kinds of communities that can form, and the governance tools available to those communities.
That specificity matters because whatβs actually happening across ActivityPub and ATProto right now looks, at first glance, like chaos. There are dozens of different applications, community experiments, and governance arrangements, each making different choices about where boundaries fall and who controls what. But just as Ostrom found that the diversity of community governance systems can be generalized into a number of shared structural rules, the diversity of the open social web also has a common set of questions: where does membership begin and end, who sets the rules, how are violations monitored, and what happens when someone breaks the agreement. Protocols donβt answer these questions, but they do determine which answers are even possible.
* * *
The simplest way to understand ActivityPub is that servers send messages to each other. A person on one server can follow a person on another server, and when either of them posts something, their server delivers that message to the other. That simplicity hides a deeper question though: what is a server actually for?
The answer that dominated for most of Mastodonβs history is that a server is infrastructure. In a 2023 interview with The Verge, Mastodon founder Eugen Rochko described the product in terms that made servers sound like an implementation detail. βThink about it like email, and youβll get it. If you donβt like Gmail, you can switch to something else, but you donβt have to quit email entirely as a concept.β When users complained about having to choose a server at signup, Rochkoβs response was to make the choice disappear: sorting the server list to show larger servers first, adding a βpick for meβ button, and keeping mastodon.social open as a default funnel. He acknowledged this moved Mastodon closer to the Gmail problem he said he wanted to avoid, but framed it as necessity, saying: βHowever, Iβve learned over the years that there is no replacement for having a default, right?β
In this model, the server boundary is administrative rather than social. Users experience a single network where the fact that their account lives on one server rather than another is, ideally, something they never have to think about, with the server handling uptime, storage, and moderation enforcement. The social graph extends freely across server boundaries and the home feed pulls in content from everywhere, making it feel like a single network.The topology is functionally centralized even though the infrastructure is distributed. This solves some problems regarding engineering and the distribution of power, but does so without creating distinct social spaces.
Mastodonβs current leadership is trying to move away from this. Their new community director, Hannah Aubrey, describes Mastodon as βa front door, not the whole house,β and talks about surfacing and supporting other servers rather than funneling everyone into mastodon.social. Director Felix Hlatky has made distributing users away from mastodon.social an explicit priority, noting that concentrating users on one server is βnot the purpose of building a social network.β The target is ambitious: going from roughly 10,000 servers to 100,000, which Hlatky says βneeds a mindshift in what it means to start a server.β
In this newer model, the server boundary becomes a social boundary, and your experience of Mastodon is supposed to be shaped by the community you joined rather than just by who you follow across the wider network. Aubrey envisions server starters as βleaders and organizersβ who want to build something for their community, whether that community is defined by language, identity, geography, or shared interest, framing the value proposition in terms of belonging: βyou can still be in community with people in a safe and healthy way.β
Instead of one network with distributed infrastructure, it is a network of networks where each node has meaningful social coherence. Newsmast, a UK-based organization building ActivityPub infrastructure for publishers and communities, is pushing this further by creating branded apps on top of individual server communities that combine community feeds with a publisherβs content. The logical conclusion of their approach is one app per community, with federation as the connective tissue between them.
Lemmy and PieFed, the Reddit-style link aggregation platforms on ActivityPub, complicate this further. Communities (the equivalent of subreddits) exist on servers but are accessible from other servers, creating a double layer of social boundaries: a community has its own topic, its own moderators, and its own norms, but it also lives on a server that has its own administrators and its own moderation policies. When users from one server participate in a community hosted on another, it is genuinely unclear whose norms apply. The server boundary and the community boundary overlap without aligning, producing a topology of mixed jurisdictions that nobody has fully figured out how to govern.
(PieFed also has a feature called βTopicsβ, which aggregates posts from multiple communities into a single feed around a single theme, making jurisdiction a truly joyful mess: a single post can be made by someone on server A, posted into a community hosted on server B, and then aggregated into a Topic hosted on server C. What happens when rules between servers A, B and C conflict is anyoneβs guess.)
The point here is that ActivityPub does not prescribe a single topology. The protocol is flexible enough that each application makes a fundamentally different choice about how much the server boundary matters socially. Mastodon circa 2023 treated servers as invisible plumbing; Mastodon in 2026 wants servers to be communities. PeerTube treats them as institutional containers for self-hosted video libraries, with federation as a secondary feature. Lemmy layers communities on top of servers, creating overlapping boundaries.
* * *
In ATProto, every user has a Personal Data Server (PDS) that stores their content as structured records, and applications donβt host this data but read from it. The mental model is something like a shared lake of public data: every PDS contributes its stream, and every application draws out the subset relevant to its purpose. A microblogging app reads posts, while a video app reads video records and a code hosting platform reads repositories, all from the same pool of data, through different lenses. Where ActivityPub organizes around the server as the social unit, ATProto organizes around data.
Bluesky is the dominant application built on ATProto, and for most users it is simply a Twitter-like social network. Community formation in Bluesky is supposed to happen through custom feeds, and Bluesky CEO Jay Graber has framed these as the platformβs core innovation. βThe algorithm, more than the content type or the appβs appearance, is the core of social media because it directs how you spend your attention there,β she wrote in 2023, describing Blueskyβs goal as replacing the βmaster algorithmβ controlled by a single company with an open βmarketplace of algorithms.β The language is consistently about individual choice and control: what you see, what you scroll, what you subscribe to. Blueskyβs own FAQ makes the contrast with Mastodon explicit: βOn Mastodon, your instance, or server, determines your communityβ¦ On Bluesky, your experience is based on what feeds and accounts you follow, and you can always participate in the global conversation.β
But community is not an attention problem. Feeds organize what individuals see without creating shared spaces, shared governance, or shared membership. In Blueskyβs default implementation, you scroll a feed but you donβt belong to it. The absence of community infrastructure at the feed level follows directly from what feeds were designed to do: they solve for individual curation, not collective organization. This is not a protocol-level constraint, though, as the case of Blacksky demonstrates: a feed can carry community infrastructure when it is deliberately built to do so, with dedicated moderation and explicit membership. But Blueskyβs affordances push toward the passive-consumption model rather than the community-building one.
This is a problem for anyone trying to build actual community on ATProto. Blacksky, which serves the Black community on Bluesky, shows what it actually takes. Their approach was to construct community identity first, starting with a custom feed that created a sense of shared space, then progressively building their own PDS hosting, their own moderation system, and their own relay, their own appview. Their moderation relay is particularly significant because it means any application on the network can plug into Blackskyβs moderation rather than relying solely on Blueskyβs, and their recent work on private posts represents the most explicit departure from ATProtoβs default assumption that all data is public, carving out enclosure where the protocol assumes openness.
Other community-oriented applications face similar tensions. Gander (Canada), Eurosky (EU), and Northsky (queer community) each target specific populations while maintaining a full-network view, and it remains unclear how these will develop in practice: whether the community identity or the full-network access becomes the primary experience. They are attempting to create bounded social spaces on top of a protocol that was designed to be boundaryless.
Then there are applications that donβt focus on creating social community spaces at all, and these may be where ATProtoβs architecture is most naturally suited. Tangled is a code hosting platform with social features, more comparable to GitHub than to Twitter. Margin.at allows users to write annotations on web pages that are visible to other users, an interesting reversal where the application layer spans the entire web and ATProto functions as invisible plumbing underneath. Germ, a messaging app, uses ATProtoβs identity system (DID:PLC) for user identity but builds its actual messaging infrastructure off-protocol entirely. Blento allows you to create a personal websites, with the data stored on your own PDS.
While ATProtoβs architecture trends towards a flat social topology with global data, this is not a hard constraint, and it can be used to create distinct social spaces as well.
* * *
The two protocols create mirror-image problems for community formation: ActivityPub provides boundaries but makes them difficult to experience from the outside, while ATProto makes the entire network navigable but provides no natural boundaries at all.
In ActivityPub, servers are supposed to be communities, but the architecture does not support the social mechanics through which communities actually form. You canβt visit another server or browse a different communityβs conversation the way you might walk into a neighborhood bar. And while you can follow individuals across server boundaries, you canβt be present in a space without committing your identity to it. Communities, as sociologists have long observed, tend to form through encounter, through showing up at the same place at the same time and discovering shared interests through proximity. ActivityPub supports following but not presence, and the server boundary, while it matters in theory, is not something a user can experience in practice.
Another challenge with a βserver as communityβ is that the person running a server is simultaneously the infrastructure administrator and the community leader, and these are fundamentally different roles requiring different skills. Hlatky is frank about the reality: most people who start servers βhave no idea what moderation meansβ. They come from tech background, experience a spam wave, and gradually find out what responsibilities come with running a server. Aubreyβs vision of server starters as βleaders and organizersβ building something for their community describes a different population than the people who actually run servers, and the overlap between sysadmin skills and community stewardship skills is small. Mastodonβs plan to make server hosting technically easier may widen this gap rather than close it, because the bottleneck is not the technical complexity of running Docker but the social complexity of cultivating a community.
Under the EUβs Digital Services Act, server operators are potentially regulated entities with compliance obligations around content moderation, transparency, and user protection. Mastodonβs own recent strategy announcement acknowledges this tension, committing to a regulatory audit for βour own serversβ and exploring βhow this knowledge can be shared with the community,β. The person running a Mastodon instance is now expected to be a sysadmin, a community steward, and a legally compliant service provider.
The cross-server interaction problem shows the limits of the server-as-community model. When someone from server B replies to someone on server A, and server A has cultivated specific norms around content warnings and topic sensitivity, the person on server B has never encountered those norms. Server Aβs admin can react after the fact by deleting the reply, blocking the account, or defederating from server B entirely, but there is no mechanism for communicating norms before the interaction happens. There is no door to walk through, no house rules posted at the entrance. In Ostromβs framework, functioning institutions require that participants understand the rules before they act, that monitoring is possible, and that graduated sanctions exist for violations. An ActivityPub server-as-community has sanctions but lacks the prior steps: rules arenβt visible to outsiders and monitoring is purely reactive, which means the institution has enforcement powers but not constitutive ones.
The standard counter-argument is that visiting other servers is narrowly possible: you can browse a local timeline through the web interface and follow people from a specific community. There is a difference, though, between technical accessibility and social experience. A local timeline is a raw chronological feed with no context about what the community is, what its norms are, or what makes it distinct. Compare this to Reddit, where arriving at a subreddit immediately presents the communityβs identity as a first-class interface element: its name, description, rules, moderators, visual identity. The community is a navigable object that you can encounter, evaluate, and choose to join. In ActivityPub, the community is metadata on a username, and even when you follow a cluster of people from one server, their posts appear in your home timeline mixed with everything else, the community context stripped away by the presentation layer. Community does not survive aggregation, because the interface does not preserve it.
None of this means ActivityPub servers cannot function as communities. Some do, particularly when the community existed before the server: a podcast audience, an existing forum, a professional network that migrated together. But in those cases, the community coheres despite the architecture rather than because of it, with the server providing infrastructure for something that was already socially real. Building community through encounter, the way most communities actually form, is much harder when the architecture provides no mechanism for encounter.
For ATProto, where community lives is an even more open question. In ActivityPub, the answer is at least clear: community lives on the server. That answer may be structurally difficult to realize, but everyone in the ecosystem shares a common understanding of where community is supposed to be. In ATProto, different projects are testing fundamentally different answers, and the protocol itself is agnostic between them. Applied through Ostromβs lens, the question becomes: which of these answers can actually produce functioning institutions with clear rules, meaningful monitoring, and graduated sanctions?
The first candidate is the feed. Blueskyβs own framing positions feeds as the primary mechanism for user agency: a marketplace of algorithms replacing the singular Algorithm, giving individuals control over their attention. But as Blueskyβs FAQ itself makes clear, the design priority is participation in the βglobal conversation,β with feeds as personalization layers on top of that global view rather than as bounded spaces. In institutional terms, a feed has no rule-making capacity, no monitoring function, and no sanctions. It organizes attention but does not organize people.
The second candidate is the appview, which aggregates network data and presents it as a coherent application, making choices about indexing, display, moderation, and features. This is why Blacksky building their own appview is significant: it created a fully independent social space governed by community-chosen moderators and presenting community-curated content. If community lives in the appview, then the appview operator is the place-maker, and ATProto communities form around whoever is willing to build and maintain that aggregation infrastructure. Of the candidates, the appview comes closest to supporting Ostromβs institutional requirements, because the operator can establish rules, monitor behavior, and apply graduated sanctions, though the appview alone does not control identity or data, which limits the boundaries it can draw.
The third answer is the full infrastructure stack. Blacksky did not just build an appview: they built PDS hosting, a relay, a moderation system, and eventually private posts. Community, in their model, is not a single layer but an assembly of identity infrastructure, data hosting, moderation, application experience, and boundary enforcement. This is the most institutionally complete answer, the one that comes closest to satisfying Ostromβs full framework, and it is also the most demanding, taking Blacksky years and significant organizational capacity to construct.
It is also worth noting that this approach looks somewhat similar to the ActivityPub server model, where a single operator controls data storage, moderation, and application experience. The difference is in easier data portability and interoperability, as well as keeping identity separate from data, that ActivityPubβs server-bound architecture lacks. The implication is that the demands of community governance may impose their own architectural requirements, regardless of what the underlying protocol provides.
The last option is to focus on ATProto as a digital identity system, where your identity and data persists across applications, and your data lives on your PDS. This works as a kind of portable individual place: a bloggerβs βplaceβ follows them, with software being swappable while identity and data remain stable. Here, communities only become emergent and ephemeral, defined by your social connections. In Ostromβs terms, this is the weakest institutional answer: it provides continuity of identity but no mechanism for collective rule-making, monitoring, or enforcement. Community becomes something that happens to you through your connections rather than something you participate in governing.
Each of these answers implies a different topology. If community lives in feeds, ATProto is flat: one network, many lenses, no boundaries. If community lives in appviews, the topology resembles ActivityPubβs server model but with explicit role separation and data portability. If community lives in full infrastructure stacks, the topology fragments into a small number of heavily invested community platforms surrounded by a large number of lightweight applications that donβt attempt community at all. If community lives in identity, there is no collective community topology at all, only individual nodes.
After several years of development, the ATProto ecosystem has produced exactly one fully realized community (Blacksky) and a collection of promising projects that have not yet demonstrated they can sustain the institutional demands that community requires.
* * *
ActivityPub and ATProto are not two implementations of the same idea. They represent two different shapes of answers to the questions how should social life be organized online, where should boundaries fall, who should govern what happens within them, and what does it mean to belong? Ostrom spent a career studying how communities develop institutions to manage shared resources, and one of her central findings was that the most resilient arrangements evolved through local experimentation rather than external imposition. The successful communities she documented did not adopt a single governance template, instead they tried things, failed at most of them, and arrived at rules fitted to local condition. What worked in one context did not necessarily transfer to another, even when the resources and stakes were similar.
The open social web is in this experimental phase, and different projects are testing different answers. But these answers are not equally viable, and topologies that concentrate institutional functions, that combine rule-making, monitoring, and enforcement in a coherent operator, produce more resilient governance than those that distribute these functions across layers or leave them to emerge organically. This holds whether the starting point is an ActivityPub server or an ATProto infrastructure stack. The protocol shapes the available answers, but community governance has its own structural demands, and those demands are not infinitely flexible.
But experimentation is not the same as success, and neither protocol has yet demonstrated a scalable, repeatable model for community formation. ActivityPub has a clear answer to where community lives that turns out to be structurally difficult to realize. ATProtoβs architecture suggest a more individualised and global network, but projects like Blacksky also show that building communities is possible, even if it requires extending the protocol.
Robin Berjon, speaking in Berlin, observed that the structural properties of a protocol and the structural properties of an institution are the same. If he is right, and the evidence increasingly suggests that he is, then the question facing the open social web is not which protocol wins, but whether either ecosystem can produce the institutional designs that the communities forming within them actually need.
#nlnet
https://connectedplaces.online/where-does-community-live/ https://connectedplaces.online/where-does-community-live/
