Specifying IPFS and the InterPlanetary stack.
The technology that powers the content-addressable web is being standardized here.
We aim to fully define implementation behaviour and to empower anyone to build their own system that fits into the interplanetary ecosystem without needing to reverse-engineer the behavior of other implementations.
Comprehensive test suites
A specification is only as useful as it is both testable and tested. We are building extensive test suites that allow specifications to prove their interoperability and implementations to demonstrate their correctness.
Testing infrastructure
We build tools to support detecting interoperability issues early and often as part of CI/CD pipelines and to report on implementation maturity as the stack evolves so that people who build on top of the interplanetary stack can know what they can use in production.
An open governance model
We guarantee community ownership of the standards, of the standards-production process, and of the infrastructure to operate it, in collective pursuit of efficient, transformative, ethical technology.
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.
Meta
Meta contains all the non-technical documents that conspire to make the standards project work: what the core values are, what the governance model is, how to produce documents, etc.
- Code of Conduct
- The code of conduct that all community participants are held to.
- Spec for Specs
- Specifies the format and system used to create and maintain specifications for the interplanetary stack.
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.
HTTP Gateways
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.
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-0484: Opt-in Filtering in Routing V1 HTTP API
- 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