Spec for HTTPS-only providers on Amino DHT

> Filling public issue because this died in private channels and threads many times
> Part of work towards https://github.com/ipshipyard/roadmaps/issues/9 and https://github.com/ipshipyard/roadmaps/issues/15
> This is also helping with webseeds from https://github.com/ipshipyard/roadmaps/issues/19

> [!TIP]
> A lot of information below is from 2025 Q1 and outdated.
> Jump to my 2026 Q3 status summary in https://github.com/ipfs/specs/issues/496#issuecomment-5195385659

## Need

We need to agree and write down a specification how HTTP-only [Trustless Gateway](https://specs.ipfs.tech/http-gateways/trustless-gateway/) providers can be announced on _existing_ Amino DHT.

Such provider can have a synthetic PeerID for interop with routing systems and software, but in reality it won't have any libp2p networking stack, and only expose HTTP endpoint that follows the [Trustless Gateway](https://specs.ipfs.tech/http-gateways/trustless-gateway/) spec.

## Wider context

- **We already have big providers that have HTTP-only "PeerID" provider** (e.g. Storacha announces special peer with `/tls/http` multiaddr – right now it is only announced to IPNI)
- We already have experimental HTTP-only retrieval in `boxo`/`rainbow` that
- Detects `/tls/http` multiaddrs
- Performs [content-type negotiation / probe](https://specs.ipfs.tech/http-gateways/trustless-gateway/#dedicated-probe-paths) to confirm the HTTP endpoint supports trustless gateway protocol
- Performs HTTP-only retrieval from such provider
- **The PeerID is not used for anything.**
- There is no auth when client learns about this provider from delegated routing system that proxies to IPNI and DHT, nor IPNI runs any validation checks when it accepts such announcement.
- We want to allow people to self-host over HTTP and turn off Bitswap
- Stability and cost reduction thanks to HTTP Caching and free HTTP CDNs makes self-hosting possible with cheap hardware and with narrow bandwidth
- We can't deploy protocol changes to DHT without waiting 6-24+ months for significant % of DHT server nodes to update
- Annual reminder, that no spec for IPFS behaviors on Amino DHT exists, and if we want to make changes, need to fill this gap first: https://github.com/ipfs/specs/issues/345
- Most of people who self-host run Kubo or [IPFS Cluster](https://ipfscluster.io/) backed by a fleet of Kubo nodes that announce to Amino DHT (and some run sidecar that also announces to IPNI)

## North star

- Use this as opportunity to fill gap described in https://github.com/ipfs/specs/issues/345
- We want to leverage existing DHT clients, servers, including third-party software.
- Leverage PoC that works with Storacha, and generalize it for Amino DHT and private swarms
- Make it possible for existing users to run Kubo-based node/cluster that only exposes [non-recursive](https://github.com/ipfs/kubo/blob/master/docs/config.md#gatewaynofetch) [Trustless Gateway](https://specs.ipfs.tech/http-gateways/trustless-gateway/) over HTTPS and [has Bitswap Server shut down](https://github.com/ipfs/kubo/issues/10717)

## Proposed spec direction

- use `/tls/http` in announced Multiaddr as signaling method
- document that libp2p peers should follow libp2p+http spec for coexistence of multiple services on the same HTTP endpoint
- for libp2p specific ones, follow https://specs.ipfs.tech/http-gateways/libp2p-gateway/#well-known-libp2p-protocols to discover libp2p protocols supported by the HTTP endpoint → https://github.com/ipfs/specs/pull/495
- for http-only retrieval, follow plain HTTP content type negotiation (Accept header) and probing convention documented in [trustless-gateway spec](https://specs.ipfs.tech/http-gateways/trustless-gateway/#dedicated-probe-paths)
- this keeps system open-ended – HTTP-based transfer protocols can be added the same way, all they need to do is to use new content-type in `Accept` / `Content-Type` header
- document that HTTP-only [Trustless Gateway](https://specs.ipfs.tech/http-gateways/trustless-gateway/) clients can ignore PeerID → https://github.com/ipfs/specs/pull/495

## Open questions

1. Any concerns with using `/tls/http` in announced Multiaddrs for this?
- Example: is it ok for Kubo user to put their [`Gateway.NoFetch=true`](https://github.com/ipfs/kubo/blob/master/docs/config.md#gatewaynofetch)&[`Gateway.DeserializedResponses`](https://github.com/ipfs/kubo/blob/master/docs/config.md#gatewaydeserializedresponses) gateway behind Cloudflare and URL in `Addresses.AppendAnnounce` as `/dns4/gw.example.com/tcp/443/tls` as extra hint for clients that prefer HTTP-only retrieval?
- afaik we have all specs necessary for reliable interop – see spec direction above, but comment below if any spec gaps exist
1. If content providers start announcing their trustless, non-recursive gateways as `/dnsX/example.com/../tls/http`, do we need any auth of DNS names?
- Should DHT nodes accept and gossip `/dnsX/example.com/../tls/http` addrs blindly or should extra validation be added at routing system level (DHT, IPNI)?
- Following prior art of ACME challenges, we need to think about HTTPS on raw IPs, or other setups without access to DNS. We could require a signed peerid published on DNS TXT or as HTTP GET file on `.well-known/libp2p/signed-peerid` path, but this complicates deployments, requires people to deal with PeerIDs, and at the end of the day, how is this auth request any better from HTTP client blindly sending a [trustless probe](https://specs.ipfs.tech/http-gateways/trustless-gateway/#dedicated-probe-paths) `GET /ipfs/cid` and getting 404 indicating endpoint is not a valid gateway?

As usual, ideas, feedback welcome.