IPFS

  • Name: IPFS
  • URL: https://ipfs.tech/
  • Category: content-addressed data protocol / peer-to-peer retrieval and routing infrastructure / decentralized web primitive
  • Summary: IPFS is the naming-and-routing base layer. It tells you how content-addressed data gets named, found, and moved; it does not by itself solve durable storage. That is why it is the baseline note for this branch. Keep the protocol note separate from protocol-labs, the originating organization boundary behind IPFS, Filecoin, and libp2p.
  • What it does:
    • Identifies content by content identifiers (CIDs) derived from hashed blocks and codec metadata rather than by server location
    • Organizes files, directories, and linked data as Merkle-DAG structures through IPLD and UnixFS
    • Routes requests for content using peer-to-peer mechanisms such as the Kademlia DHT, Bitswap, delegated routing, and libp2p connectivity
    • Transfers requested blocks directly between peers or through HTTP gateways and CAR-file based transport paths
    • Supports mutable naming and publishing layers like IPNS and DNSLink above otherwise immutable content-addressed objects
    • Leaves persistence to node operators, local pins, managed pinning services, or incentive layers such as Filecoin rather than guaranteeing indefinite retention by itself
  • Key claims:
    • The official docs explicitly define IPFS as a set of open protocols for addressing, routing, and transferring data on the web, which is the cleanest classification signal: IPFS is a protocol suite, not a hosted storage service
    • The concepts docs say IPFS is not itself a storage provider or cloud service, which matters because it prevents the common mistake of treating IPFS as synonymous with durable storage
    • The architecture docs show that IPFS’s main subsystems split cleanly into data representation, content routing, and data transfer, making it analytically useful as a modular base layer rather than a monolith
    • The content-addressing docs show why CIDs are not simple file hashes: IPFS chunks and structures data into DAGs, which means the real abstraction is verifiable graph-addressed content, not just checksums
    • The persistence docs are especially important because they state plainly that IPFS does not guarantee persistent availability; data survives only if nodes keep it, pin it, or arrange a storage incentive layer
    • The original paper describes IPFS as something like a single BitTorrent swarm exchanging objects inside one Git-style content graph, which is still one of the most useful analogies for understanding what IPFS changes and what it leaves unsolved
    • In corpus terms, IPFS is the baseline distinction-maker: it helps separate projects optimizing for discoverability and retrieval from projects optimizing for durable custody, permanence economics, or proof-backed storage guarantees
  • Whitepaper: The original IPFS whitepaper has been saved locally as ../whitepapers/ipfs-whitepaper.pdf. See also ../whitepapers/ipfs-primary-sources-2026-05-09.md.
  • Sources:

Internal linkages

Control surface

  • IPFS itself is the protocol baseline for content addressing, routing, and transfer.

  • Keep that separate from protocol-labs, which is the more useful note when the question is about the originating organization, implementation lineage, and ecosystem-shaping influence above the protocol.

  • Read the durable risk here as protocol-versus-organization separation: IPFS can be open and modular while still carrying strong lineage and packaging gravity from one named builder network.

  • Last reviewed: 2026-08-11 UTC