Summary

  • RFC 9518 says technical decentralisation may be necessary but is not sufficient: standards can lower switching costs without deciding market structure.
  • A credible exit must be tested across exportable state, substitute discovery, identity continuity, cross-provider interoperability and network-effect loss.
  • Standards-track status, federation diagrams and centralisation reviews are evidence about architecture, not proof of implementation diversity, adoption, enforceable rights or user mobility.

The exit begins where the specification ends

A team can publish a clean protocol, define a portable file and draw several interchangeable providers. The resulting diagram looks decentralised. A buyer still may be unable to leave.

The old provider may hold settings that were never included in the export. The replacement may implement the wire format but omit the feature that matters. Contacts can remain reachable only inside the incumbent network. A stable identity may be attached to an account that cannot move. The user's audience, suppliers or collaborators may remain concentrated on the old service. Nothing in the packet format forces a provider to accept the incoming state, operate a bridge or honour the same contractual rights.

That gap is the most useful reading of RFC 9518. Mark Nottingham's document was published in December 2023 as an Independent Submission and Informational RFC. It is not an Internet Standards Track specification and does not represent IETF consensus. Its authority here is analytical: it identifies what standards work can change and what lies beyond its reach.

The document defines centralisation in terms of exclusive power to observe, capture, control or extract rent from an Internet function. That is not the same as a technical single point of failure. A service can be redundant across many machines and still leave decisive control in one commercial hand. Conversely, some common coordination points can be useful when their authority is narrow and accountable.

The standard therefore should not be judged by whether it carries a decentralisation label. It should be judged by the options it makes executable.

Five interfaces make an exit testable

The first interface is exportable state. Data portability is only the visible layer. A useful export must carry the semantics required to reconstruct the service: settings, permissions, histories, relationships, evidence, identifiers and the version needed to interpret them. A dump that is complete in bytes but ambiguous in meaning is an archive, not a migration instrument.

The second is substitute discovery. RFC 9518 argues that switching requires alternatives and therefore breadth in implementations and deployments. One open-source codebase operated under several brands may provide commercial choice without meaningful implementation diversity. Several codebases that depend on one distribution gate may reproduce the same control point. The test is whether an independent destination is available, maintained and capable of receiving the relevant state.

The third is identity and contact continuity. Users rarely value data alone. They value the identity by which counterparties recognise them, the credentials that prove control, the addresses through which people find them and the reputation accumulated under those identifiers. If departure requires starting again as an unknown actor, the technical export can succeed while the economic exit fails.

The fourth is cross-provider interoperability. Migration is not always a midnight cutover. Old and new users may need to communicate during a long transition. A recipient needs to answer using the same semantics. A bridge must preserve security boundaries and disclose what it cannot translate. Federation is relevant here, but RFC 9518 is explicit that federation creates conditions for decentralisation rather than guaranteeing it. Voluntary compliance, operating cost and the leverage of large nodes still shape the outcome.

The fifth is network-effect loss. A user can carry every record and still lose the market, audience or collaboration graph that made the service useful. This is the decisive distinction between a protocol affordance and market power. The standard can expose contacts, define messages and reduce conversion work. It cannot manufacture counterparties at the destination or erase an incumbent's data, capital, default-distribution and brand advantages.

Together these interfaces form an exit receipt. None should be treated as a binary checkbox. The receipt should record what moved, what was rejected, the time and expertise required, functionality lost, third parties that had to coordinate, the ability to return and the outcome after the switch.

Completeness and diversity pull in opposite directions

RFC 9518 describes a design tension that procurement teams often miss. A specification must be complete and precise enough to support substitution. Yet excessive complexity raises the cost of a new implementation and can leave only the largest vendors able to comply. A thin standard can have the opposite failure: the essential functions migrate into proprietary extensions, so nominally conforming products cannot replace one another.

RFC 5218 adds a related caution: protocol success is a deployment phenomenon, not merely a publication event. A specification can be technically sound without producing diverse, sustained implementation. The relevant evidence is therefore not the label on the document but compatible products, independent operators, successful imports and repeatable switches.

Heng Lu's Minimum Initial Specification sharpens the boundary. The common layer should contain the deterministic rules needed for interoperability and shared safety; required coordination artefacts should be portable, auditable, reproducible and replaceable. That design keeps the shared layer thin, but it does not abolish the need to examine power above it.

Law and incentives remain outside the wire format

Technical standards are generally voluntary. RFC 9518 notes that law can mandate interoperability where publication alone cannot, and points to measures such as the Digital Markets Act. The distinction matters. A schema can describe an export. It cannot itself require timely access, prohibit retaliation, allocate migration cost, preserve a contractual identity or provide a remedy when the incumbent sends an incomplete file.

Legal rights are not substitutes for architecture either. A badly designed mandate can require unsafe access or freeze a flawed interface into law. The durable combination is narrower: a technically coherent switching surface, independent implementations, enforceable duties and evidence that ordinary users can exercise them.

This is why a mandatory “Centralization Considerations” section would be a weak proxy. So would a standards-track badge or a federation diagram. Each can improve discussion. None measures whether a user has a destination, can preserve value or can compel cooperation.

Sources and limits

This analysis relies on RFC 9518, RFC 5218, Lu Heng's design note and the text of Regulation (EU) 2022/1925. It does not measure present market shares, switching rates or the conformance of any named service. RFC 9518 is an author's Independent-stream analysis, not an IETF consensus position. The five-interface test is an editorial synthesis for evaluating exit conditions, not a claim that passing it proves a competitive market.