Open lidel opened 5 months ago
@lidel I don't know if that fix is quite enough. If the delegated routing endpoints are being used for IPNS resolution (as opposed to using the trustless gateway endpoints) then we still need them around even if not doing direct retrievals.
We could at the Helia level not turn on the content or peer routing systems though (or potentially use the trustless gateways for IPNS fetch).
Yes, the idea here is to have "quality of life" toggle that disables all delegated routing, and only relies on trustless gateways.
You can still do IPNS via trustless gateways alone, but if verified-fetch does not leverage it yet, we can simply error on IPNS errors, informing user they need to enable delegated routing.
This seems like a duplicate of #267.
@lidel I don't know if that fix is quite enough. If the delegated routing endpoints are being used for IPNS resolution (as opposed to using the trustless gateway endpoints) then we still need them around even if not doing direct retrievals.
That's right. Currently, Helia is built in a way that accepts 3 kinds of routers (libp2p, delegatedHTTPRouting, and httpGatewayRouting) and by default includes both delegatedHTTPRouting
, and httpGatewayRouting
. The problem is that if we remove the delegatedHTTPRouting, there's no way for Helia to Resolve IPNS names.
I've opened https://github.com/ipfs/helia/issues/558 to address this gap in Helia.
Descoping from Camp milestone due to impact on DNSLink (see https://github.com/ipfs/service-worker-gateway/pull/303#pullrequestreview-2148664363).
Do we still want to do this? I think the only action item here would be to disable delegated routing if direct retrieval is not enabled and trustless gateways are enabled.
Current state
service-worker-gateway
sends a lot of requests tohttps://delegated-routing.dev
but (afaik) we don't have direct retrieval yet, so there is no benefit from itProposed UX fix