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:
- https://ipfs.tech/
- https://docs.ipfs.tech/
- https://docs.ipfs.tech/concepts/what-is-ipfs/
- https://docs.ipfs.tech/concepts/how-ipfs-works/
- https://docs.ipfs.tech/concepts/persistence/
- https://docs.ipfs.tech/concepts/content-addressing/
- https://docs.ipfs.tech/concepts/further-reading/academic-papers/
- https://github.com/ipfs/specs
Internal linkages
- Best anchors: filecoin, arweave, and storacha.
- Company boundary for origin and ecosystem-shaping gravity: protocol-labs.
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