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:

429 Too Many Requests - Throttles by the gateway maybe because have hit bandwidth limits for this common good.
500 Internal Server Error - Internal issue to gateway setup.
502 Bad Gateway - Issue with the downstream that the gateway is fetching from.
504 Gateway Timeout - Timeout fetching from the downstream.

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

Improve Helia’s performance and request management (will happen in Open)
Likely need to improve delegated routing to make life easier Helia (will happen in Open)
Add support in boxo/gateway to forward to Helia on error
Clean up rough edges around service worker support

Service worker caveats:

At most, service workers can only intercept requests being made to the root origin of the page (e.g., example.com in the case of https://example.com/myimages/index.html). If https://example.com/myimages/index.html has <img src="https://ipfs.io/ipfs/CID">, the service worker won’t be invoked because ipfs.io ≠ example.com
More information: https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers

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

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

What this is

Why this is a good idea

What we need to do

What would success look like?

Related Items