While some of these tools use HTTP itself, it would also be nice if they could use the same semantics but without the requirements of CA certs (+ domain names), public IP addresses, etc. To enable this we can use HTTP over libp2p.
This proposal is to start by enabling an optional server for Trustless Gateway over libp2p, and future issues may tackle support for client support as well.
The relevant pieces are:
Use the relevant HTTP over libp2p specs and go-libp2p implementation (e.g. .well-known support, etc.)
Add an (experimental) flag to enable support to enable support for the protocol
Note: check for any conflicts with the Experimental.P2pHttpProxy feature
Note: ensure the trustless gateway exposed this way runs with Fetch disabled Gateway.NoFetch=true (only return blocks that are in local repo and 5XX (502?) for the rest?)
2023-08-29 conversation on testing this:
We need a bridge from HTTP/1.1 that passes it to libp2p stream layer.
We'll be running conformance a second time in trustless mode against this proxy port.
Description
The trustless gateway specification allows retrieval of blocks and certain types of DAGs over HTTP.
Some tooling has already been built that leverages the trustless gateway API to move data around (https://github.com/little-bear-labs/ipfs-chromium, https://github.com/ipfs/bifrost-gateway, https://github.com/filecoin-project/lassie, helia-enabled service worker, etc.).
While some of these tools use HTTP itself, it would also be nice if they could use the same semantics but without the requirements of CA certs (+ domain names), public IP addresses, etc. To enable this we can use HTTP over libp2p.
This proposal is to start by enabling an optional server for Trustless Gateway over libp2p, and future issues may tackle support for client support as well.
The relevant pieces are:
.well-known
support, etc.)Experimental.P2pHttpProxy
featureGateway.NoFetch=true
(only return blocks that are in local repo and 5XX (502?) for the rest?)