Closed MarcoPolo closed 8 months ago
@MarcoPolo keeping it simple sounds sensible, but perhaps nest with /
to be /ipfs/gateway
to follow existing convention (/ipfs/bitswap
etc)?
We don't need to specify if it is trustless,if it supports only blocks or cars here, as that will be signalled via HTTP POST mechanism from IPIP-425.
2023-08-29 conversation: @aschmahmann will take this. He's planning to create src/http-gateways/libp2p-gateway.md (which is needed for https://github.com/ipfs/kubo/issues/10049)
As libp2p+HTTP work advances, it would be good to define what the
protocol.ID
should be for the IPFS gateway protocol. This is just a string that serves as the canonical name for this protocol. It's useful for signaling support for IPFS gateway to peers. In libp2p+HTTP, this will be included in the.well-known/libp2p
(the HTTP equivalent of identify), along with a path prefix metadata (this path prefix could be "/"). In the future I would expect something similar to maybe be included in peer records and IPNI metadata (there's already something similar in IPNI).This can be as simple as
/ipfs-gateway
.As an example, a libp2p+http node that supports
/ipfs-gateway
mounted at/
would return this under/.well-known/libp2p
:This tells other peers that this node supports the IPFS gateway protocol and it's mounted on the root path (
"/"
). This system would also work if we wanted to mount it somewhere else as well.This works exactly the same when run on top of a libp2p stream, except the HTTP/1.1 message is sent over a new libp2p stream (using protocol.ID
/http/1.1
as defined in the HTTP spec).Just for completeness, not directly relevant to this, A peer advertises HTTP support by either advertising an HTTP transport in its multiaddr and/or advertising support for
/http/1.1
in libp2p's Identify protocol.Once we agree on a canonical protocol.ID for the gateway protocol, I don't mind opening a PR.