IPFS 0.5.0 Rewrote Content Routing for a Larger Peer-to-Peer Web

The IPFS project released go-ipfs 0.5.0 on April 28, 2020, delivering a broad rewrite of content routing and a major refactor of data transfer in the most widely used implementation of the InterPlanetary File System.

The signed GitHub release was posted on April 28 and described roughly 2,500 commits, 98 contributors and more than 650 pull requests across IPFS, libp2p and multiformats. Those are project-reported development totals, not measures of network adoption. The consequential change was architectural: software used to locate and exchange content-addressed data was rebuilt to spend less time querying unreachable peers and to terminate searches more efficiently.

IPFS was not a blockchain or a cryptocurrency. It addressed files by cryptographic content identifiers and used peer-to-peer networking to find providers and transfer blocks. Its importance to the digital-asset sector came from its role as a storage and distribution layer for decentralized applications, Ethereum-linked naming, and other systems that sought to avoid dependence on a single web host.

The routing layer was rewritten

IPFS nodes used a distributed hash table, or DHT, to advertise which peers could provide particular content. The 0.5.0 release notes identified three problems in the preceding design: many peers could not be reached through firewalls or network-address translation; queries often continued until timeout after reaching the useful end of a search; and routing tables could degrade as the network grew.

Version 0.5.0 separated local-area and public-internet routing into two DHTs. A node would wait for evidence that it was publicly reachable before serving the wide-area DHT, while all nodes could participate in local discovery. Query logic was brought closer to Kademlia behavior, routing tables prioritized responsive peers, and provider records were announced by multihash rather than a full content identifier.

That last change addressed cases in which identical bytes could be named through different CID versions or codecs. It also introduced a compatibility limitation: the release notes warned that 0.5.0 nodes could fail to find CIDv1 content announced by older nodes, and vice versa. The project expected limited impact because CIDv1 was not enabled by default, but encouraged coordinated upgrading.

Faster claims came with defined limits

The project said routing and providing were already two to three times faster. It reported file adding at up to twice the prior speed when using the Badger datastore on Linux or macOS, and said providing an IPNS record was 30 to 40 times faster in simulations of 1,000 nodes or more. A same-day Cointelegraph report relayed broader project benchmarks of two-to-five-times faster fetching and two-to-six-times faster provider discovery.

These were release benchmarks and simulations, not an independent audit of the public network. Results depended on datastore choice, operating system, network conditions, content availability, peer versions and test configuration. The release notes also cautioned that the refactored Bitswap protocol would show little download improvement until both sending and receiving peers had upgraded.

Security and application compatibility

The release made TLS the preferred connection transport while retaining SECIO compatibility, enforced a minimum 2,048-bit RSA key size and changed peer-address notation from an `/ipfs/` suffix to `/p2p/`. Gateway subdomains placed applications in separate browser origins, and the local API began accepting POST rather than GET requests to tighten cross-origin security.

Those changes could require adjustments by operators and application developers. Experimental Graphsync support could serve data but could not yet fetch it; QUIC remained experimental; and the higher-performance Badger datastore was declared stable but was not the default and carried memory and corruption tradeoffs described by the maintainers.

The April 28 record therefore supports a measured conclusion: go-ipfs 0.5.0 materially changed how IPFS nodes discovered peers, advertised content and exchanged blocks. It did not prove that decentralized storage had displaced conventional hosting, guarantee persistence of any file, or establish the later success of applications built on the protocol.