Closed achingbrain closed 2 months ago
I'm curious, how do you plan on using the HTTPGatwayRouter once merged?
how do you plan on using the HTTPGatwayRouter once merged?
It'll be configured like any other router and will let http gateway sessions fall back to a default set of gateways.
We'll also be able to switch the gateway block broker over to use the helia routing which will let it find non-preconfigured gateways but also fall back to the default ones.
I'm curious, how do you plan on using the HTTPGatwayRouter once merged?
Some context for @2color from chat I had with @achingbrain when talking about issues with trustless-gateways related to testing out the changes in https://github.com/ipfs/helia-verified-fetch/pull/50
Basically I’m not sure we’re ready for HTTP Gateway sessions yet. To that end I’ve put this PR together that adds a routing implementation that just returns a static list of gateways - https://github.com/ipfs/helia/pull/515 This way when we get better HTTP results via the delegated lookup in the future we can just turn off the static list.
Essentially, we need some way to reduce the breadth of content-fetching requests (via sessions), and trustless gateways returned from delegated routing providers are not consistently reliable and frequently not available at all.
When I was looking into it, I proposed having trustless gateway sessions fall back to the provided trustless-gateways passed to blockBrokers. IIUC, this PR enables a version of that fallback in the defined "routing" language we've recently moved to in helia.
Alex to correct me here if I'm wrong or too imprecise.
That's it, all good.
Nice! Cool stuff
Adds a routing implementation that returns a static list of gateways as providers for CIDs.
It's expected that these gateways are able to fetch content on our behalf.
Depends on:
Change checklist