IPFS Solved Content Addressing. It Didn't Solve Naming, Persistence, or Governance.

IPFS made a precise and correct observation about the web: content should be identified by what it is, not where it is stored. A file addressed by its cryptographic hash is verifiable anywhere, retrievable from any peer that holds it, and immune to link rot caused by servers going offline or URLs changing. Content addressing is a genuinely better model than location addressing for a distributed system.

That insight produced a protocol that works. IPFS is real infrastructure. Developers build on it. Filecoin extends it with storage incentives. ENS and other naming systems reference it. The content addressing model it introduced has influenced how the web thinks about data identity.

The problem is that content addressing solves one problem and defers three others: persistence, naming, and governance. Those three problems all have the same structural root, and IPFS's current solutions to them all introduce centralization through the back door.

The persistence problem

In IPFS, content exists on the network as long as at least one node is pinning it. Pinning means a node has explicitly committed to keeping a piece of content available rather than allowing it to be garbage collected. If no node is pinning a CID, that content becomes unreachable.

This is not a bug. It is a deliberate design choice: IPFS does not force nodes to store content they did not choose to store. The consequence is that content persistence requires an active decision by someone to maintain it.

In practice, most developers who need reliable persistence delegate that decision to a centralized pinning service: Pinata, Infura, Filebase, and others. These services maintain the infrastructure that keeps content available. They are the de facto persistence layer for most IPFS deployments. The content is addressed in a decentralized way. The guarantee that it remains available is provided by a centralized service.

The naming problem

Content addressing by hash is immutable by design. Change a file and its CID changes. This is the property that makes content addressing trustworthy. It is also the property that makes it unusable for anything that needs to be updated.

IPNS (InterPlanetary Name System) addresses this by providing mutable pointers: an IPNS name is a hash of a public key, and the owner of the corresponding private key can update what the name points to. The name stays stable while the content it references changes.

The structural problems with IPNS are specific. IPNS records published to the DHT expire after 48 hours and must be actively republished. IPFS's own specification confirms this: records must have an expiration time set within 48 hours after publication. A name that is not actively maintained disappears from the network.

Resolving an IPNS name via DHT requires collecting responses from a quorum of 16 out of 20 DHT servers before returning a result. This is slow in practice, which is why IPFS's own documentation notes that DNSLink is "currently much faster than IPNS." The workaround most developers reach for is an IPFS gateway. IPFS's documentation is explicit about the tradeoff: "IPNS resolution via an IPFS gateway is trusted, which means you delegate IPNS resolution to the gateway without any means to verify the authenticity of the response."

The naming layer has re-centralized around gateways and pinning services for the same reason the persistence layer did: the protocol provides the mechanism but not the infrastructure to operate it reliably at scale.

The governance problem

Neither content addressing nor IPNS provides any mechanism for a segment of the namespace to define its own mutation policy, coordinate cache state across the nodes responsible for it, or make governed structural decisions about how the namespace evolves.

An IPNS name is owned by whoever holds the private key. That person can update what the name points to. What they cannot do is define who else can propose updates, what conditions those proposals must meet, how updates should be validated across multiple nodes, or how the history of updates should be preserved and traversable. There is no concept of scoped governance in IPFS's naming layer. There is ownership, and there is the DHT.

The cache coordination problem is similar. Content is cached at nodes that have recently accessed it and garbage collected when it has not been accessed recently or when the node needs space. There is no mechanism for the nodes responsible for a given namespace scope to coordinate on what should be cached, when cache state should be invalidated, or how cache policy should be defined and enforced locally. Those decisions happen through individual node behavior and centralized pinning, not through governed coordination among the nodes responsible for a given scope.

What the three problems share

Persistence, naming, and governance are three symptoms of the same structural gap: IPFS has no mechanism for a scope of the namespace to be governed by the nodes responsible for it.

Content addressing works without scoped governance because it is stateless: a CID is a hash, verification is cryptographic, no coordination required. The moment you need mutability (naming), persistence (cache coordination), or policy (access control and mutation governance), you need a coordination mechanism. IPFS defers that coordination to the DHT for naming, to pinning services for persistence, and to nothing in particular for governance. The DHT and the pinning services both re-introduce centralization because they are the only available coordination mechanisms.

Scoped governance means: the nodes responsible for a given segment of the namespace hold the policy for that segment, mutations are proposed and validated through local consensus among those nodes, cache state is coordinated within the scope, and the history of changes is preserved in a lineage that remains traversable. This is what the adaptive index provides: a hierarchical namespace where each scope is anchor-governed, resolution traverses the hierarchy stepwise through local anchor groups, and structural changes preserve lineage continuity.

IPFS's content addressing model and the adaptive index's governance model are not in competition. Content addressing identifies what a resource is. Anchor-governed scopes determine how that resource can be named, found, updated, and persisted without delegating those decisions to centralized infrastructure.