A network without coordination is not a network. If two programs disagree on the format of a message, they cannot interpret it. If two networks use incompatible identifiers, they do not know where to forward data. If every implementation decides on its own what a signature means, none can verify the others.
Interoperability requires agreements.
This fact often leads to a hasty conclusion: if common rules are necessary, some authority must define and enforce them, and decide who may participate. But coordination and sovereignty are not the same. The former allows independent agents to cooperate. The latter grants someone ultimate power over the rest.
The difference seems abstract until a technical rule becomes an instrument of admission, exclusion, or surveillance. Whoever controls an indispensable identifier can erase a presence. Whoever operates the only directory can make someone impossible to find. Whoever is legally liable for everything they carry gains an incentive to inspect every communication.
The first article in this series showed how architecture shapes the interventions that are possible. This one takes a step back and asks how rules can be shared without creating a sovereign over the network.
A standard describes; it does not need to command
The Internet offers an imperfect but instructive example. The IETF produces technical specifications so that implementations developed by different people and organizations can work together.
Its mission statement, RFC 3935, describes an open process, technical competence, rough consensus, and implementation experience. In defining a standard, the document draws a crucial distinction: a specification explains how to perform a function interoperably; it does not seek to mandate adoption or police its use.
This does not eliminate power, disputes, or barriers to participation in standardization. Nor does it make every technical decision neutral. The RFC itself acknowledges choices such as decentralized control and empowering users at the edges. What the model demonstrates is more limited and valuable: shared rules can be published for independent adoption and implementation without every packet requiring permission from the organization that wrote them.
A standard coordinates behavior. It does not need to command participants.
Many local decisions, one global network
Routing provides another example. The Internet consists of autonomous networks that choose how to connect and where to forward traffic. They share protocols and identifiers, but they do not consult a global controller before every decision.
The Internet Society captures this property in the idea of decentralized management: local decisions, common protocols, and a distributed system produce global reach.
The example should not be romanticized. Dominant operators, resource registries, commercial agreements, and governments constrain real choices. Errors or malicious actions can propagate illegitimate routes. Distributed coordination does not mean an absence of dependencies; it means that no single operational decision is, by design, the universal authorization for the network to exist.
This difference suggests a test. A coordinating component approaches sovereignty when its decision is simultaneously mandatory, exclusive, and irreplaceable. The harder that decision is to verify, challenge, or replace, the more power the component accumulates.
Common numbers do not require a worldwide participant registry
Today's Internet combines different forms of numerical coordination. IANA maintains parameter registries so that, for example, a protocol code has the same meaning in independent implementations. It also coordinates the global spaces of IP addresses and autonomous system numbers, distributed hierarchically through regional registries. Both involve numbers, but their functions differ: one records the protocol vocabulary; the other allocates operational resources that must be globally unique. (IANA, number resources)
PRP needs the first kind of coordination. Versions, cryptographic suites, types, and fields must have interoperable interpretations. Its specifications therefore maintain public, versioned, verifiable registries. Changing the meaning of a published assignment requires another value or another version.
This does not create a worldwide numbering plan for agents. Self-certifying identities derive from cryptographic material itself. Relationship identifiers, session handles, and route selectors belong to qualified contexts and may repeat the same numerical value in independent contexts. There is no global allocation from which every person must obtain a number before participating.
Current PRP specifications request no IANA action. This is not a promise of institutional isolation: future standardization may register parameters through public processes. The architectural property is different. Even if common codes are eventually published in an external registry, IANA does not thereby issue PRP identities, relationships, sessions, routes, or permissions.
Operational independence and protocol coordination are compatible. Everyone must agree on what a field means; nobody must consult a worldwide registry to decide who may use that field in a local relationship.
When administration means authorization
Not every coordination center is avoidable. Global parameters must prevent collisions. Versions must be recognizable. Some relationships depend on statements made by third parties. The problem is not the mere existence of a specialized service, but the extent of its power.
There is a difference between publishing a verifiable list and owning the only catalog; between attesting to a relationship and granting identity; between offering one discovery path and being able to make someone invisible through every path.
Contemporary platforms frequently accumulate these functions. The same company creates the account, defines the name, stores the content, chooses the audience, recommends the publication, and can terminate the relationship. Its coordination is convenient, but also sovereign within that space: full continuity does not exist once the operator withdraws permission.
A decentralized architecture can reproduce this problem under different names. Distributing servers is not enough if they all depend on the same identity issuer, the same registry, or the same mandatory policy. The right question is not how many machines exist. It is who can issue a final “no.”
When the messenger is liable for the message
The same boundary appears in the legal liability of infrastructure. If a means of transport is automatically liable for everything its users do, it must reduce its own risk. The economically predictable response is to observe more, block earlier, and accept fewer participants.
The seventh principle of the CGI.br Principles calls this non-liability of the network: action against unlawful conduct should target those ultimately responsible, not the means of access and transport, while preserving freedom, privacy, and human rights.
This position is not exclusively Brazilian. The Manila Principles advocate protection for intermediaries regarding third-party content, reject obligations of proactive monitoring, and require restrictions to be specific, necessary, proportionate, and subject to due process. In the European Union, Articles 4 through 8 of the Digital Services Act preserve distinct regimes for mere conduit, caching, and hosting, while also ruling out a general monitoring obligation.
These documents do not have the same legal nature and do not provide absolute immunity. A provider may have duties of its own and be liable for its own conduct. A platform that selects and recommends content does not perform the same role as a network that merely carries data. The important principle is proportionality to role: responsibility should follow an agent's specific actions and capabilities, rather than radiate indiscriminately through every layer.
Responsibility at the edges
Preventing infrastructure from knowing or judging every communication does not prevent criminal accountability. It architecturally prevents the protocol from enforcing a universal prevention policy over those communications.
Authors remain subject to the law. Devices can preserve evidence. Victims and participants can report conduct. Services can define policies for relationships in which they take part. Authorities can investigate specific targets and obtain evidence through legally available means.
What ceases to exist is a shortcut: turning every intermediary into a preventive monitor of every user. This boundary does not solve the problem of abuse. It defines where an investigation must occur and prevents the possibility of a crime from turning every communication into a permanent object of inspection.
An architecture always distributes capabilities. If the means of transport can read, classify, and prevent any relationship, someone will be able to demand that it do so. If it cannot, legitimate responses must be directed at agents and evidence at the edges.
Coordination in PRP: common rules, local decisions
PRP shares rules, not an authority with day-to-day power over relationships. Independent implementations interpret the same formats and verify the same validity conditions. This enables interoperability without giving any one implementation the power to admit or exclude all participants.
Each agent decides which relationships to accept and which resources to make available within them. A refusal applies to the relationship in question: it does not erase the other agent's identity or determine whom that agent can communicate with elsewhere on the network.
The distinction is between understanding a message and agreeing to what it proposes. Two agents can correctly interpret the same request and reach different decisions according to their policies. The common rule lets them understand each other; it does not require them to make the same choices.
Verifiable coordination
The criterion can now be stated more precisely. Coordination without sovereignty requires:
- public rules that independent implementations can execute;
- common registries for interpreting the protocol, without a universal
numbering plan for participants;
- independent implementations capable of interoperating;
- different local policies that can coexist;
- participation and access decisions limited to each agent's relationships;
- separation between defining the protocol and authorizing its use;
- replacement of components without losing every identity and relationship.
This architecture does not eliminate governance. Specifications still evolve, implementations still diverge, and policies still need to be chosen. It changes the object of coordination: instead of concentrating day-to-day decisions about who may speak to whom, it coordinates formats through which independent agents can interpret messages, verify their validity, and decide how to respond.
In the first article, we saw how addresses and intermediaries became control points over relationships the network does not understand. The next step is to examine the most direct mechanism behind that confusion: when an order aimed at content or conduct is enforced against an address and reaches everything that shares that location.
Coordination is indispensable. Technical sovereignty is not.