Native HTTP across the IPFS Stack, to enable Filecoin direct retrieval

Trustless gateway-based HTTP retrieval alongside Bitswap in Kubo and Helia

ETA

Q1-Q2

Expected impact

Compatibility with Filecoin SPs who are only incentivized via Spark to perform HTTP retrievals (anecdotally many turn off bitswap to save resources because they’ll still pass the Spark scores)
Large IPFS providers can more easily enable accessibility of their content from web browsers (only those running kubo and web3.storage do this today, nobody else has enabled Secure WebSockets or WebTransport)
Large IPFS providers can leverage HTTP infra, CDNs, etc. to reduce their operational complexity and costs

Progress reporting

Q1

• Shipped HTTP retrieval support in Boxo and Rainbow.
  • Made sure Filecoin providers running outdated Boost (with missing HTTP HEAD support) can still be used
  • Enabled HTTP-only retrieval on ipfs.io/dweb.link with Storacha, to test and evaluate HTTP retrieval performance
• Ongoing spec work to allow use of /tls/http providers in Amino DHT as backup routing system (to allow one-time instant announcement of new CIDs without waiting for slower systems like IPNI to catch up)
  ...

Q2

• Shipped and evaluated the opt-in HTTP Retrieval client in Kubo: feat: opt-in http retrieval client ipfs/kubo#10772

• Enabled by default in Kubo 0.36.0-rc1: feat: HTTP retrieval enabled by default ipfs/kubo#10836

• https://check.ipfs.network: Add support for testing HTTP retrieval ipfs/ipfs-check#73

• Can be considered done when Kubo 0.36.0 is out.