libp2p+HTTP Transport Gateway Specification

status: draft
History
Commit History
Feedback
GitHub ipfs/specs (inspect source, open issue)

This specification describes how HTTP Gateway semantics and APIs can be used over libp2p transports, and how libp2p can coexist with other HTTP services on the same host.

1. libp2p HTTP Protocols Manifest

The libp2p+HTTP specification describes how to use libp2p with HTTP semantics over stream transports, as well as how to do discovery of what protocols are available (and where they are mounted).

1.1 .well-known/libp2p/protocols

Any libp2p application sub-protocols exposed behind /http/1.1 protocol can be discovered by the well-known resource ([rfc8615]) at .well-known/libp2p/protocols.

1.1.1 Protocol Identifier

In order for a pure HTTP Gateway protocol like the [trustless-gateway] to coexist with libp2p in this environment it requires a protocol identifier to act as a key in the .well-known/libp2p/protocols mapping file.

The /http/1.1 sub-protocol identifier for the IPFS Gateway when used over libp2p is:

/ipfs/gateway

1.1.2 Protocol Mounting

A reference .well-known/libp2p/protocols JSON body with mapping that assumes the gateway to be mounted at /:

{
  "protocols": {
    "/ipfs/gateway": {"path": "/"},
  }
}

2. Peer ID Authentication

Peer ID Authentication over HTTP is optional and SHOULD NOT be required by Trustless Gateway HTTP endpoint defined for /ipfs/gateway handler.

Clients following the Trustless Gateway specification MUST verify each CID individually, without being concerned with peer identity. PeerID authentication is not required for trustless retrieval and HTTP-only clients SHOULD work without it.

3. Gateway Type Detection

The /ipfs/gateway protocol identifier is shared among all Gateway specifications.

An HTTP server mounted behind the /ipfs/gateway identifier MUST expose the most basic block (application/vnd.ipld.raw) responses from [trustless-gateway], but MAY also support other gateway types and features.

Client implementations SHOULD perform feature detection on their own, or assume only the most basic block (application/vnd.ipld.raw) response type from [trustless-gateway] is available.

A. References

[rfc2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[rfc8615]
Well-Known Uniform Resource Identifiers (URIs). M. Nottingham. IETF. May 2019. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8615
[trustless-gateway]
Trustless Gateway Specification. Marcin Rataj; Henrique Dias; Héctor Sanjuán. 2025-03-06. URL: https://specs.ipfs.tech/http-gateways/trustless-gateway/

B. Acknowledgments

We gratefully acknowledge the following individuals for their valuable contributions, ranging from minor suggestions to major insights, which have shaped and improved this specification.

Editors
Adin Schmahmann (Shipyard) GitHub
Marcin Rataj (Shipyard) GitHub