Supporting multiple delegated routing endpoints

[2color]

Background

We currently support multiple routers, i.e., delegated routing endpoints.

In the past, these were passed directly to Verified Fetch, however, when we create Verified Fetch with js-libp2p, this becomes challenging, because we instantiate js-libp2p with the delegated routing service which only supports one endpoint.

The only way around this is to create js-libp2p without the delegated routing service and do something as we do in the Verified Fetch constructor:

routers: ...(config?.routers ?? ['https://delegated-ipfs.dev']).map((routerUrl) => delegatedHTTPRouting(routerUrl)),
..

Open questions

• Is there really a use-case for multiple delegated routing endpoints? Is that something we want to support?
• How will js-libp2p (that is passed into Helia) behave if it has neither a DHT Client nor a Delegated Routing service, while there is/are delegated router(s) in Helia (with delegatedHTTPRouting(routerUrl))). In other words, if Helia handles routing, does the underlying js-libp2p instance also need a routing mechanism?

[achingbrain]

if Helia handles routing, does the underlying js-libp2p instance also need a routing mechanism?

Yes, if routing operations are invoked. This may happen behind the scenes, e.g. if we interact with an RSA peer and we don't have their public key, we (should) go to the routing to fetch it.

libp2p doesn't know about Helia so it can't call the Helia routing to do the same thing. If it did it'd end up invoking itself since it's the routing implementation for Helia.

we instantiate js-libp2p with the delegated routing service which only supports one endpoint

You can use multiple instances of the delegate routing service with different endpoints?

Is there really a use-case for multiple delegated routing endpoints?

I wouldn't want to take it off the table entirely, but it's going to be quite chatty so you'd probably want to think carefully about configuring that.

---

If we have libp2p routing for Helia, is there any reason to not just configure only libp2p with the http gateway routing? That is, do we need libp2p+http-routing and http-routing too or can we just use libp2p+http-routing?

[2color]

You can use multiple instances of the delegate routing service with different endpoints?

Good to know that's not a constraint. I see in the code that libp2p checks for the content and peer routing symbols in every service.

---

If we have libp2p routing for Helia, is there any reason to not just configure only libp2p with the http gateway routing?

Having read your response, that makes sense.

That is, do we need libp2p+http-routing and http-routing too or can we just use libp2p+http-routing?

Do you mean "libp2p+http-routing and delegated-http-routing"?

---

It is fair to sum it up as follows:

When using Helia with libp2p and delegated routing, defined the delegated routing client on the libp2p layer. For each delegated routing endpoint, instantiate a libp2p service

routers.forEach((router, i) => {
  libp2pOptions.services[`delegatedRouter${i}`] = () => createDelegatedRoutingV1HttpApiClient(router, { filterProtocols: ['unknown', 'transport-bitswap', 'transport-ipfs-gateway-http'], filterAddrs })
})

[achingbrain]

Do you mean "libp2p+http-routing and delegated-http-routing"?

I'm talking about the Delegated Routing V1 HTTP API, not the HTTP Gateway Routing from @helia/routers.

Very confusing names 😕

It is fair to sum it up as follows

Yes, that sounds correct.