IPFS Standards

Specifying IPFS and the InterPlanetary stack.

The technology that powers the content-addressable web is being standardized here.

Specifications

The specifications are broken up into multiple areas that cover the stack.

Architecture

These documents define the architectural principles that IPFS is built upon, and can be used as tools to evaluate implementations and applications of IPFS.

IPFS Principles: IPFS is a suite of specifications and tools that are defined by two key characteristics: content-addressing and transport-agnosticity. This document provides context and details about these characteristics. In doing so it defines what is or is not an IPFS implementation.

Routing

Routing is the way to determine where to find a given content, peer, or IPNS record.

Delegated Routing V1 HTTP API: Delegated routing is a mechanism for IPFS implementations to use for offloading content routing, peer routing and naming to another process/server. This specification describes an HTTP API for delegated routing of content, peers, and IPNS.
Bitswap Protocol: Bitswap is a libp2p data exchange protocol for finding, sending and receiving content addressed blocks of data. It attempts to acquire blocks from the p2p network that have been requested by the client, and also send blocks to others who want them.

Exchange

Exchange is the way to for sending and receiving content-addressed blocks of data.

Bitswap Protocol: Bitswap is a libp2p data exchange protocol for finding, sending and receiving content addressed blocks of data. It attempts to acquire blocks from the p2p network that have been requested by the client, and also send blocks to others who want them.
Trustless Gateway Specification: The minimal subset of HTTP Gateway response types facilitates data retrieval via CID and ensures integrity verification, all while eliminating the need to trust the gateway itself.
libp2p+HTTP Transport Gateway Specification: Describes how HTTP Gateway semantics can be used over libp2p transports.

IPFS Gateway acts as a bridge between traditional HTTP clients and IPFS. Through the gateway, users can download files, directories and other IPLD data stored in IPFS as if they were stored in a traditional web server.

Low-level HTTP semantics:

Path Gateway Specification: The comprehensive low-level HTTP Gateway enables the integration of IPFS resources into the HTTP stack through /ipfs and /ipns namespaces, supporting both deserialized and verifiable response types.
Trustless Gateway Specification: The minimal subset of HTTP Gateway response types facilitates data retrieval via CID and ensures integrity verification, all while eliminating the need to trust the gateway itself.
libp2p+HTTP Transport Gateway Specification: Describes how HTTP Gateway semantics can be used over libp2p transports.

Web semantics (for website hosting and web browsers):

Subdomain Gateway Specification: Defines how HTTP Gateway can implement support for HTTP Host headers to enable isolated website hosting based on root CID-derived Origins. This ensures compatibility with native ipfs:// and ipns:// URIs, and aligns with the existing Same-origin security model in web browsers, including relative URL pathing and permission scopes of Web APIs.
DNSLink Gateway Specification: Defines how to utilize the HTTP Host header to serve a content path from a DNSLink record as a website under a particular DNS name.
Web _redirects File Specification: Defines how URL redirects and rewrites can be implemented by adding rules to a plain text file stored underneath the root CID of a website.

Data Formats

IPFS basic primitive is an opaque block of bytes identified by a CID. CID includes codec that informs IPFS System about data format: how to parse the block, and how to link from one block to another.

The most popular data formats used by IPFS Systems are RAW (an opaque block), UnixFS (filesystem abstraction built with DAG-PB and RAW codecs), DAG-CBOR/DAG-JSON, however IPFS ecosystem is not limited to them, and IPFS systems are free to choose the level of interoperability, or even implement support for own, additional formats. A complimentary CAR is a codec-agnostic archive format for transporting multiple opaque blocks.

Specifications:

UnixFS: UnixFS is a Protocol Buffers-based format for describing files, directories, and symlinks as dag-pb and raw DAGs in IPFS.

IPNS

The InterPlanetary Naming System (IPNS) is a naming system responsible for creating, reading and updating mutable pointers to data.

IPNS Record and Protocol: Specifies the IPNS protocol in a language-agnostic manner, allowing everyone to create a compatible IPNS Record Publisher or Resolver.
IPNS PubSub Router: Specifies how to publish and retrieve IPNS records using libp2p PubSub router.

Content Filtering

How IPFS service operators can control the content hosted on their nodes.

Compact Denylist Format: How content blocking rules can be represented as a .deny file.

InterPlanetary Improvement Proposals

InterPlanetary Improvement Proposals (IPIP) are an orderly mechanism to consider changes to the IPFS specification. They are not changes to the specification itself, but their approval leads to a change in the specification.

IPIP-0428: Allowing V2-Only Records in IPNS
IPIP-0417: Delegated Peer Routing HTTP API
IPIP-0412: Signaling Block Order in CARs on HTTP Gateways
IPIP-0410: Streaming NDJSON in Routing HTTP API
IPIP-0402: Partial CAR Support on Trustless Gateways
IPIP-0386: Subdomain Gateway Interop with _redirects
IPIP-0383: Compact Denylist Format
IPIP-0379: Delegated IPNS HTTP API
IPIP-0351: IPNS Signed Records Response Format on HTTP Gateways
IPIP-0337: Delegated Content Routing HTTP API
IPIP-0328: JSON and CBOR Response Formats on HTTP Gateways
IPIP-0288: TAR Response Format on HTTP Gateways
IPIP-0002: _redirects File Support on Web Gateways
IPIP-0001: Lightweight Improvement Process for IPFS Specifications