Recently, Paul Frazee, the CTO of Bluesky, published a blog post titled “Practical Decentralization.” “The point of decentralization,” Frazee writes, “is to guarantee the rights of individuals and communities on the Internet.” And: “We use protocols to structure who can do what. Protocol designs are often about the how, but the consequence of the how is an authority model.”
On this account, protocols are governance structures whose design choices allocate power, and the purpose of the entire enterprise is the protection of rights. Protocol design is a form of political design, and the appropriate way to evaluate protocols is not only by their technical properties but by the governance outcomes they produce.
Stafford Beer, the management cybernetician, had a phrase for this kind of claim: ‘the purpose of a system is what it does.’ Not what it intends, not what its designers hope for, but what it produces. Applied to four decades of open protocol history, the pattern is consistent: protocol design can constrain how actors operate within a system, but it cannot ensure the conditions that keep the broader ecosystem functioning. The newer protocols engage with governance and power far more directly than their predecessors did, but the distance between architectural intent and operational reality has proven resistant to even the most thoughtful design.
The early protocols
SMTP, the protocol that carries email, says almost nothing about its purpose: its stated objective is a single sentence, “to transfer mail reliably and efficiently,” and that sentence has served as the protocol’s entire account of its own purpose across three major revisions and more than four decades. It says nothing about who should send or receive email, nothing about privacy or identity, nothing about power. The protocol describes a mechanism for moving messages between servers, and what those messages contain, who sends them, and what consequences follow from their delivery are questions it declines to consider.
HTTP, the protocol that carries the web, is similarly spare: it exists to “enable flexible interaction with network-based hypertext information systems.” Tim Berners-Lee’s original 1989 proposal says more, framing the problem as knowledge management at CERN and including an explicit requirement for “Non-Centralisation,” the principle that information systems should be linkable without requiring any central control or coordination. But the protocol emerged from a specific institutional context, a physics laboratory whose internal culture treated openness as a working assumption rather than a contested political commitment.
RSS and XMPP follow the same pattern. RSS is barely more than a data format reference, with no stated purpose at all. XMPP states that its purpose is “to enable the exchange of relatively small pieces of structured data over a network between any two or more entities.” It describes a mechanism, but does not explain why the mechanism should exist or what values it serves.
The early open protocols describe what they do in purely functional terms: they transfer mail, serve hypertext, syndicate content, exchange structured data. They are silent about why these capabilities matter, who they serve, what kinds of social arrangements they enable, and what governance structures they take for granted. When these specifications use the word “purpose,” they mean technical function, not social aim.
The silence reflected an engineering culture in which protocols were understood as infrastructure, and infrastructure was assumed to be politically neutral. A road does not have an opinion about who drives on it, a power grid does not care what appliances are plugged into it. The engineers who wrote these protocols, working within the IETF and its predecessor communities, treated interoperability and open access as engineering defaults, properties a well-designed system ought to have, rather than political commitments that needed to be explicitly secured.
The POSIWID question for these early protocols is: what is the result of treating protocols as neutral infrastructure? SMTP’s radical permissiveness, the fact that any server can send to any server with no authentication, enabled both universal email and universal spam. It also enabled email to become the foundational identity layer of the internet, a function no one designed it to serve and that no part of its specification anticipates. HTTP’s host-centric authority model, in which the server is authoritative for its resources, enabled both the open web and the consolidation of the web into a handful of platforms. Missing layers for state management, identity, payment, and trust were filled by actors whose business models then determined where the network went. RSS gave publishers a way to distribute their work independently but offered no mechanism for collective curation, and the vacuum that absence left was filled, eventually, by algorithmic platforms. XMPP’s federated architecture mirrored email’s and inherited the same portability limitations, which made it vulnerable to the same kind of corporate instrumentalization. Google did not need to break XMPP federation or defeat the protocol on its own terms. It only needed to stop federating, which it did once its proprietary network had absorbed enough users that the protocol’s openness no longer served its interests.
In each case, the protocol’s silence about governance, power, and purpose did not produce a neutral outcome but a highly specific one: the concentration of power in the hands of actors who could build on top of the protocol’s open infrastructure without being constrained by its openness. There is a fundamental asymmetry at work here: protocol design can constrain how actors operate within a system, but it cannot secure the conditions that keep the broader ecosystem functioning. A protocol can say “if you participate, these are the rules,” but it cannot say “you must keep participating,” or “you may not accumulate power in the layers adjacent to this one.” The silence about purpose was not the absence of politics but a politics of non-interference, and its beneficiaries were predictable: whichever actors had the resources to build in the space the protocols left ungoverned.
Protocols with purpose
ActivityPub’s specification calls itself “a decentralized social networking protocol,” but the specification says nothing about why decentralization matters or what it is supposed to achieve. The normative reasoning for the protocol lives elsewhere: ActivityPub co-authors Christine Lemmer-Webber and Evan Prodromou have written extensively about user freedom, resistance to corporate control, and the social web as a commons. The specification itself says nothing about content moderation, community governance, abuse prevention, or the power dynamics between large and small instances, and each of these became a major practical challenge within a few years of the protocol’s adoption. The designers had strong views about what the protocol was for, but the protocol itself did not encode, protect, or even mention those views.
Where ActivityPub’s normative commitments remained outside its specification, Matrix puts them inside it directly, including the declaration that secure communication is a human right. ATProto goes further still, embedding normative commitments directly in its technical documentation: “speech and reach should be two separate layers,”, and “everyone has a voice.”
Where previous generations of protocols only describe mechanisms, newer protocols also articulate missions. But ATProto represents something beyond this progression. It is the first protocol to integrate normative commitments directly into its technical documentation rather than leaving them to blog posts and conference talks. If any protocol has closed the distance between designer intent and protocol purpose, it is this one, which makes it the most informative case for asking whether closing that distance changes what the protocol actually produces.
What protocols actually do
POSIWID, though, does not care about intentions, not even explicit ones. What ActivityPub has produced, in practice, is a network of independently operated servers whose coordination depends on bilateral trust relationships between their administrators. The practical consequence is that your server’s administrator is the single most important governance actor in your social media experience, more important than any protocol feature or network-level norm. They control your identity, because your address takes the form user@server; your data, because it is stored on their hardware; your reach, because they decide which other servers to federate with; and your ability to leave, because migration requires their cooperation and discards your accumulated social context.
This is centralized control relocated rather than removed, from a corporation to a server administrator, and whether this is an improvement depends on scale: a small community-run instance can hold its administrator accountable in ways no platform user can hold a corporation accountable, but a large instance like mastodon.social reproduces platform dynamics at a smaller scale. The fediverse is not a set of interchangeable servers between which individual users move according to preference; it is a network of semi-autonomous communities whose primary governance mechanism is the ability to sever connection with one another. If we apply Beer’s principle, the protocol’s purpose is not “decentralized social networking” but something closer to “community sovereignty exercised through selective connectivity, with the costs and benefits of that sovereignty distributed unevenly across the network.”
Large instances exercise disproportionate influence over the network’s norms and patterns of connectivity. Instance-level blocking, designed as a community safety tool, also functions as a coercive mechanism, because a popular instance’s block list becomes a de facto standard when smaller instances cannot afford to be cut off from the network’s social center of gravity. Exclusion, in other words, is the fediverse’s core governance mechanism, which is close to the inverse of what the phrase “open protocol” usually implies. What results is governance by social pressure and administrator discretion, without formal mechanisms for accountability, appeal, or collective decision-making at the network level.
ATProto produces a different structure, with its own challenges. The separation of identity from hosting, which means your handle is portable and your data lives in a cryptographically signed repository that can move between servers, addresses the identity lock-in problem that plagues ActivityPub. But the current operational reality is also that Bluesky the company dominates in the operation of all infrastructure, and it is larger than other operators like Blacksky and Eurosky by at least three orders of magnitude, which means that every layer the architecture was designed to distribute is in practice controlled by a single entity. The protocol’s architecture permits competition at each layer, but the dynamics of a shared data space favor convergence on a single provider at each layer. Not because the market has not had time to work but because actors in an ungoverned shared space imitate each other’s choices, and that imitation is self-reinforcing: the more participants use a given moderation service or AppView, the more attractive it becomes.
Frazee is honest about this: “Bluesky is still too large of a player.” It is worth noting that not all gaps between stated and revealed purpose are equivalent. An architecture can secure some rights before it secures all the ones it aspires to protect, and ATProto’s PDS layer does genuinely lower the cost of keeping your data outside the primary application operator’s control. But if we define ATProto’s purpose by what it currently does, the answer is not “a decentralized social protocol with separated powers” but “a social protocol with architectural provisions for decentralization, currently operated as a near-centralized system.” Whether those architectural provisions will translate into actual distribution of power depends on economic and institutional developments that no amount of protocol design can guarantee.
Of the protocols examined here, Matrix’s operational reality comes closest to its stated purpose. The protocol does what it says it does: it enables end-to-end encrypted, federated communication with no single point of control. Its adoption by the French government and the German military is real-world validation of its security and governance properties that few other open protocols can claim. But Matrix also shows where protocol-level governance runs out. Room-level power levels provide a mechanism for governance, not a framework. The hard problems of community governance, including how to handle persistent bad actors who move between rooms, how to balance open federation with safety, and how to fund infrastructure sustainably, are not solved by the protocol’s mechanisms but deferred to the communities that use it.
Where does governance live?
The protocols examined here span more than forty years, and in that time the design community’s relationship to questions of governance and power has changed substantially. The early protocols said nothing about these questions; the recent ones engage with them directly, articulating rights, naming values, and treating the political implications of technical design as part of the design problem.
But none of them, whether silent about governance or explicit about it, has produced a working account of how the shared resources their ecosystems generate should be governed by the communities that depend on them. The reason is that this work cannot be done within the terms the protocol design tradition has set for itself. A design tradition built on individual rights and architectural modularity does not have the conceptual resources to produce the collective governance institutions that make an ecosystem sustainable, because governance is not a feature that can be added to a protocol but an institutional arrangement that operates on top of, alongside, and sometimes in tension with the technical architecture.
Every protocol that supports social interaction at scale generates shared resources, including interconnected communities whose health depends on collective norms, search indexes, relay infrastructure, shared moderation tooling, and software ecosystems whose maintenance requires sustained coordination. These resources are not owned by any individual participant but are instead collectively produced through the participants’ interactions with one another and with the shared infrastructure. They cannot be governed by individual choice alone, because their value depends on coordination, and they cannot be governed by a single central authority without recreating the platform dynamics the protocols were designed to escape. All of the functions that make a protocol ecosystem work, such as infrastructure, abuse mitigation, discoverability, and software maintenance carry real costs, and those costs do not distribute themselves evenly across the participants in the ecosystem. They concentrate around whichever actors can afford to bear them, and once that concentration happens, those actors acquire agenda-setting power regardless of whether the protocol’s stated purpose anticipated their role.
Frazee identifies part of the problem in his critique of peer-to-peer systems: “Once you introduce shared resources (the indexes) then you need to govern those resources. This is where pure p2p falls down; it has no answer for the governance of shared resources.” The observation is correct, but it applies to a broader set of architectures than Frazee’s framing suggests. Federation, including ATProto’s version of it, has no more satisfying an answer for the governance of shared resources than pure peer-to-peer does. ATProto’s layered architecture is more modular than ActivityPub’s, but modularity is a structural property of the system, not a governance framework for the ecosystem around it. Separating speech from reach specifies who can do what within the architecture, but it does not address how the collective decisions about the shared infrastructure that supports both speech and reach should be made, or by whom.
Each protocol community has arrived at an implicit answer to this question. ActivityPub delegates governance to the instance level and assumes that local accountability will produce acceptable outcomes at the network level, though nothing in the protocol ensures this. ATProto relies on competition between service providers as a sufficient governance mechanism, which presupposes that the market conditions for meaningful competition will materialize. Matrix has gone furthest toward institutional governance, placing a foundation in the role of commons custodian, though the foundation’s authority derives from convention rather than from any mechanism the protocol enforces. And SMTP, characteristically, has no opinion at all, which is itself an answer: the governance vacuum it left was filled by the actors with the deepest pockets.
What none of them provides is something that has been studied extensively in other fields, most notably by Elinor Ostrom: design principles for the governance of common-pool resources by the communities that depend on them. Ostrom’s central finding was that communities can successfully govern shared resources without either privatization or central authority, which directly addresses the assumption, shared across the protocol communities examined here, that the only available alternatives are market competition among providers and centralized control by a single operator. But Ostrom demonstrated that this third path requires specific institutional conditions, including clearly defined boundaries around the resource and its users, proportional distribution of costs and benefits, collective choice arrangements that give participants a voice in rule-making, accessible conflict resolution mechanisms, and recognition by external authorities of the community’s right to self-govern. The open protocol ecosystem, as it currently exists, has none of these features at the network level.
Frazee’s “Information Civics” framing is pointed in the right direction: the civic tradition is precisely about the relationship between individual rights and collective governance. But Information Civics as Frazee describes it has the rights side and not the other. What it lacks are the collective-choice arrangements, defined community boundaries, and accessible conflict-resolution mechanisms that Ostrom identified as necessary conditions for communities to govern shared resources successfully. The framing names the problem space without yet providing the institutional vocabulary to work within it.
The trajectory of the earlier protocols showed clearly enough that silence about governance does not produce neutrality but leaves the governance function to be filled by whichever actors have the most resources. But the deeper point is that protocol design choices do not merely leave governance unaddressed but actively shape it, because every architectural decision makes some governance arrangements natural and others difficult or impossible. ActivityPub’s binding of identity to server makes administrator-level governance the natural default. ATProto’s separation of layers makes market competition between providers the path of least resistance. A protocol does not need to encode governance explicitly in order to shape it; it shapes governance by determining which mechanisms are easy to build, which are hard, and which are effectively impossible within the constraints the architecture imposes.
The open protocol community has inherited two intellectual traditions, both inadequate to this problem: an engineering functionalism that treats protocols as neutral infrastructure whose political consequences are someone else’s concern, and a governance minimalism that treats any collective decision-making structure as a potential vector for the very centralization the protocols were designed to prevent. The result is a community that has developed exceptional sophistication about technical architecture and individual rights while remaining largely inarticulate about collective governance. Addressing this will require the protocol design community to draw on intellectual traditions it has not yet seriously engaged with, including Ostrom’s institutional analysis, Beer’s organizational cybernetics, and the broader literature on commons governance and cooperative design.
The governance gap extends beyond the question of who controls infrastructure into the epistemic properties of the ecosystem itself: what information it surfaces, what it selects for, what vision of public discourse it produces. When the governance of a shared reach layer is left to economics, the result is not only that well-resourced actors control infrastructure but that the information dynamics of the ecosystem converge in predictable ways, because the same incentive structures that determine who can afford to operate at scale also determine what content those operators are rewarded for surfacing. An ungoverned curation layer in a connected population does not produce the diversity the architecture permits; it produces convergence on whatever the connected population most actively engages with, and the resulting homogeneity is but the natural output of a system in which reach is governed by convention rather than by institutional design.
What purpose requires
To return to Frazee’s claim: “The point of decentralization is to guarantee the rights of individuals and communities on the Internet.”
The word “communities” is doing more work in that sentence than the rest of Frazee’s article develops. The protocol design community has thought seriously about the rights of individuals: the right to host your own data, to move your account, to choose your algorithm, to speak without being deplatformed, to communicate securely. These rights are encoded in the newer protocols with varying degrees of success. The rights of communities are harder to specify and harder to protect, because they require mechanisms for collective decision-making, norm enforcement, and institutional persistence that no current protocol provides at the network level, and that even the most thoughtful protocol designers have acknowledged remain unsolved. Individual rights without institutional support are not self-sustaining: the right to migrate your account is only meaningful if there are viable alternative providers to migrate to, and the existence of viable alternatives depends on institutional conditions, including economic sustainability, governance legitimacy, and collective investment in shared infrastructure, that rights alone cannot produce.
The purpose of a protocol is what it does, and what the current generation of open protocols has produced is a commons without a governance framework adequate to the commons’ own complexity. Architectural decentralization does not automatically produce operational decentralization, because the dynamics of shared spaces without governance favor mimetic convergence rather than the pluralism the architecture permits. When participants in a shared ecosystem independently select which relay to use, which AppView to trust, which moderation service to adopt, they do not choose in isolation but in reference to each other’s choices, and the resulting convergence is self-reinforcing: what begins as a contingent adoption pattern hardens into a convention that acquires the appearance of necessity. Social media infrastructure that gets used by millions of people is expensive, especially once video gets involved. The entities that fund that infrastructure will dictate the revealed purpose of the protocol, because they became the focal point around which the ecosystem’s convergence organized itself, which is a different thing from winning a competitive market even though it produces a similar result, and once that convergence has occurred, the architecture’s theoretical openness offers little practical leverage against it.
What comes next requires the protocol design community, which has made genuine progress in articulating rights and building architectures that protect individual autonomy, to recognize that the governance of shared resources cannot be derived from the intellectual traditions it currently works within, and to draw instead on fundamentally different ones: not just the technical architecture that brings shared resources into being, but the institutional arrangements that manage them, the collective-action mechanisms that sustain them, and the design principles, drawn from commons governance, organizational cybernetics, and cooperative design, that can help ensure they serve the communities that depend on them rather than the actors best positioned to capture them. This is the work that no protocol specification has yet attempted to describe. The question that remains is what forms of power protocols can actually prevent, what forms they merely relocate from one set of actors to another, and what forms they silently generate, because every shared function eventually has to be governed by someone, and whoever governs it acquires power over the people who depend on it. An open protocol that does not answer the governance question will still receive an answer, but it will be written by whichever actors make themselves indispensable first. And the answer economics writes will determine not only who controls the infrastructure but what the ecosystem selects for, because the same dynamics that concentrate operational power also concentrate curatorial power, and the resulting information environment will reflect the priorities of whoever governs the reach layer, whether or not anyone intended to give them that authority.
