Gateway: define a protocol.ID for the gateway protocol.

[MarcoPolo]

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:

$ curl -v localhost:51654/.well-known/libp2p 
*   Trying 127.0.0.1:51654...
* Connected to localhost (127.0.0.1) port 51654 (#0)
> GET /.well-known/libp2p HTTP/1.1
> Host: localhost:51654
> User-Agent: curl/8.0.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Length: 30
< Content-Type: application/json
< Date: Wed, 16 Aug 2023 20:43:30 GMT
< 
{"/ipfs-gateway":{"path":"/"}}

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.

[lidel]

@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.

[BigLep]

2023-08-29 conversation: @aschmahmann will take this. He's planning to create src/http-gateways/libp2p-gateway.md (which is needed for ipfs/kubo#10049)