This is an issue to track potentially adding more routing endpoint default to someguy. At the moment, we ask the DHT and cid.contact. The question is: should we also ask delegated-ipfs.dev? Only that one? Or both?

Quoting @lidel from #50 (comment):

I think we need to discuss (here or in #24 (comment)) a policy for cases like this one, because whatever we decide here, the same PR could/should be applied to Kubo and Rainbow.

On one hand, makes sense to leverage delegated-ipfs.dev more, allows people to benefit from public caching utility that supports peer and ipns routing and Amino DHT proxy (the https://cid.contact/routing/v1 endpoint does not provide any of these things).

Do we

• (A) keep both here and accept duplicated IPNI (cid.contact) results for improved resiliency,
• (B) or is it better to remove cid.contact from being hardcoded in our software (since we are not ones operating that IPNI instance) and hide it behind our caching proxy, which already talks to cid.contact and caches results?

cc @aschmahmann

And

Question: how do we avoid cycles in waterworks-infra when someguy with this PR is deployed to delegated-ipfs.dev?
I think we want to avoid a situation where someguy is sending query to itself. Is the plan to set SOMEGUY_PROVIDER_ENDPOINTS="https://cid.contact" SOMEGUY_PEER_ENDPOINTS="" SOMEGUY_IPNS_ENDPOINTS="" in waterworks-infra?

That should be enough, but if we ever need a more generic solution, we could look into ipfs/specs#426.