IPFS — Content Addressed, Versioned, P2P File System

“IPFS — Content Addressed, Versioned, P2P File System” is Juan Benet’s 2014 design paper for a peer-to-peer system that addresses data by content. It proposed a combination of content-addressed blocks, a Merkle DAG, peer routing, and block exchange. The paper is a historical draft. Current IPFS is a set of protocols and tools; the draft does not describe every present-day implementation or guarantee that data will remain available. Read Benet’s paper record and the current IPFS overview.

Publication and scope

Benet’s paper was submitted on July 14, 2014. It describes a proposed peer-to-peer file system and draws on distributed hash tables, Git’s Merkle-DAG model, and peer-to-peer block exchange. Its goal was to make content-addressed data easier to locate and transfer across a distributed network. Read it as the design proposal it was; current IPFS specifications and documentation have evolved since that draft. The Protocol Labs Research copy identifies the document as Draft 3.

Content addressing and CIDs

A Content Identifier (CID) names an encoded block or the root of a linked content structure. It is built using a cryptographic multihash and self-describing information such as a codec and CID version; a text form also uses a base encoding. A CID is therefore not simply the ordinary checksum of an entire file. IPFS may split a large file into blocks and link them in a DAG, so the root identifier can differ from a checksum of the original bytes. The current IPFS guide to CIDs and the CID specification explain these fields and the difference from a file hash.

Changing the addressed content produces a different CID. This lets a reader verify that retrieved blocks match the identifier, but the CID does not say which peer has a copy or promise that any peer will keep serving it. Even identical files can receive different CIDs if they are chunked or encoded with different settings.

Merkle DAGs, files, and directories

IPFS represents linked data as a directed acyclic graph (DAG). A directory or larger file can point to child blocks by their CIDs, so a change to one block changes the identifiers of the parent path that links to it. Unchanged blocks may retain their own identifiers. UnixFS provides a file-and-directory representation on top of IPFS blocks; the full structure is not necessarily one hash over one flat file. The IPFS data-format specifications describe the codecs and UnixFS format.

Finding and exchanging content

Addressing answers what content is requested; routing helps a node find peers that can provide it. The IPFS Distributed Hash Table (DHT) stores provider records that point to peers advertising a CID, not the content itself. After finding peers, a node can request blocks using data-exchange protocols such as Bitswap. Network participants and routing records can change, so a lookup can fail when no reachable peer provides the requested blocks. The IPFS Kademlia DHT specification describes this provider lookup.

Mutable names and ordinary web access

A CID points to specific immutable content: editing the data means publishing a new CID. IPNS provides a signed, mutable name that can be updated to point to a different CID. An ipfs:// address is a native way to refer to content by CID; an HTTP gateway can expose that content through a normal https:// address for browsers and tools that do not speak IPFS. These gateway URLs make IPFS usable from the web, but IPFS does not make ordinary URLs disappear. See the IPNS record specification and the IPFS gateway guide.

Availability, pinning, and Filecoin

Finding a CID does not ensure that its data remains online. IPFS nodes may cache retrieved content and later remove unpinned data during garbage collection. Pinning tells a particular node to retain selected content; dependable access generally requires a deliberate retention plan, such as multiple independent copies. A pinning service is an operator, not a universal permanence guarantee.

Filecoin is separate from IPFS. IPFS supplies content addressing and retrieval protocols, while Filecoin provides a storage network with agreements between clients and storage providers. A CID alone does not create a Filecoin storage deal. The IPFS guide to persistence and pinning explains the limits of availability and how Filecoin relates to IPFS.

Related Terms

• IPFS
• Merkle Tree
• IPFS and NFTs

See Also

• Filecoin: A Decentralized Storage Network — storage agreements and proofs in a separate storage network.
• The Arweave Yellow Paper — an archival-storage design based on a different economic model.
• Storj: A Decentralized Cloud Storage Network Framework — a distributed object-storage design with a different architecture.

Sources

• Juan Benet, “IPFS — Content Addressed, Versioned, P2P File System” (2014) — the primary paper record for the original design and publication date.
• Protocol Labs Research, Draft 3 PDF — the available copy of the 2014 draft.
• IPFS Docs, “What is IPFS?” — a current overview of IPFS as a set of protocols and tools.
• IPFS Docs, “Content Identifiers (CIDs)” — CID construction, codecs, multihashes, and why a CID is not always a file checksum.
• IPFS Standards, CID specification — the current self-describing CID format.
• IPFS Standards, data-format specifications — codecs and the UnixFS file-and-directory representation.
• IPFS Standards, Kademlia DHT — how provider records help locate peers serving content.
• IPFS Docs, “IPFS Gateway” — HTTP gateway formats and their role in web access.
• IPFS Standards, IPNS record and protocol — signed mutable pointers to content identifiers.
• IPFS Docs, “Persistence, permanence, and pinning” — caching, pinning, availability limits, and the relationship to Filecoin.