What Does It Mean for a Protocol to Be Decentralized?
From the earlier reference collection. Read the current software blog.
Decentralization is not a single technical property. Looking separately at control, identity, hosting, and interoperability provides a more useful way to judge how a protocol works in practice.
Ask who can change the rules
A protocol is a set of shared conventions that independent implementations use to exchange information. Calling it decentralized does not by itself explain who controls those conventions or how they change. A specification maintained by one organization can still be implemented by many parties, while a nominally open protocol may depend on a single service in practice.
Look at how changes are proposed, reviewed, and adopted. Can multiple implementations participate? Are changes documented and versioned? If one maintainer can make incompatible changes without a migration path, that is a meaningful control point even if the wire format is public.
Separate identity from hosting
Identity asks how an actor or resource is named and how others verify it. Hosting asks where the associated data and software are operated. These properties are related but not identical. An account name can be tied to one provider even when messages are exchanged using an open protocol; a self-hosted service can still rely on an external identity or authentication provider.
For example, moving a server to another host may preserve a user’s data but not automatically preserve their address or relationships. To evaluate portability, ask what identifiers are stable and which mechanisms, if any, support moving or forwarding identity. Do not infer mobility from protocol openness alone.
Find the practical control points
A system may have many servers but still depend on a small number of gateways, directories, or relays. Those services can influence discovery, delivery, moderation, or access. Their role may be useful, but it should be described precisely rather than hidden behind a broad label.
A concrete review can trace a message from one user to another: where is it created, which server stores it, how is the recipient found, and which service can block or delay delivery? This path reveals operational dependencies that an architecture diagram might leave implicit.
Test interoperability, not just publication
An openly published protocol helps, but interoperability depends on implementations agreeing on details and handling differences gracefully. Try exchanging representative messages between independent implementations, including unknown optional fields and delivery failures. Note whether users can still retrieve their own data if one provider disappears.
Decentralization is best treated as a set of questions about control, hosting, identity, and cross-implementation behavior. The answers can differ across layers. A careful description says which choices users can make, what remains centrally operated, and what can fail when a key service is unavailable.