feat!: ask delegated-ipfs.dev in addition to DHT and cid.contact #50
Conversation
hacdias
force-pushed
the
default-endpoints
branch
from
d0b7b42 to
2207a9e
Compare
hacdias
force-pushed
the
default-endpoints
branch
from
2207a9e to
23ff9b8
Compare
| @@ -32,19 +32,19 @@ Default: `true` | |||
|
|
|||
| Comma-separated list of other Delegated Routing V1 endpoints to proxy provider requests to. | |||
|
|
|||
| Default: `https://cid.contact` | |||
| Default: `https://cid.contact,https://delegated-ipfs.dev` | |||
There was a problem hiding this 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
There was a problem hiding this comment.
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.
|
We can keep the discussion to #63. A PR will be made once a decision is made. |
This PR makes two changes:
askfrom cid.contact to delegated-ipfs.devTackles task in #24.