ipfs.io gateway error pages with a trustless p2p alternative (e.g., Helia)

What this is

When a user hits certain error conditions on ipfs.io/dweb.link, they are presented a one-click alternative for fetching in a more trustless/p2p fashion removing the dependency on the ipfs.io gateway infrastructure. This would get presented to users in error pages corresponding with:

We would also use this an opportunity to Drive home user options on ipfs.io gateway error pages.

Why this is a good idea

  • Increase resiliency in the system by encouraging the shift from ipfs.io being the proxy for IPFS traffic.
  • Reduce IPFS Waterworks infra spend assuming less data proxying through ipfs.io gateway
    • Note: most bandwidth comes through hotlinking video/images. Thus to really make a dent in infra spend, more aggressive steps need to be take at the ipfs.io layer like throttling of requests to certain users or referrers based on consumed bandwidth. When we do this though, we can point to the options a user have (discussed below).
  • It highlights the configurability we can have in the ecosystem.
    • The current flow is spec → kubo/boxo → ipfs.io deployment. This is expensive.
    • This change alerts developers that they can start experimenting with different IPFS functionality if they just send different JS to browsers.
  • Constant dogfooding of Helia which is a forcing function to make sure it’s actually working to satisfy expected usecases (not just atrophying to a logo on a slide)
  • Plays to a story of giving users options:
    • Limited free usage on ipfs.io
    • Point someone to host on Saturn
      • A) Pay Saturn to run a trusted gateway
      • B) Pay Saturn less to use the L1s and verify the data yourself (e.g., with a service worker… almost exactly like this one)
    • p2p fashion - Don’t pay Saturn and fetch from the network directly (e.g., with a service worker)
      • Note: Saturn B should be better than p2p option to be a viable product. It’s two advantages should be 1) Big caches near you 2) your browser should need fewer connections

What we need to do

What would success look like?

What would “good impact” look like?

  • Helia progresses to the reliability and performance point where users see little reason not to use it compared to ipfs.io gateway.
  • Helia service worker installed from ipfs.io gateway handles 5% of the requests that the ipfs.io gateway handles. (This assumes we do some instrumentation and metrics reporting of the traffic being handled by the service worker.)

Related Items

Drive home user options on ipfs.io gateway error pages