-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: ask delegated-ipfs.dev in addition to DHT and cid.contact #50
Conversation
d0b7b42
to
2207a9e
Compare
2207a9e
to
23ff9b8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs some clarifications / policy before we merge this.
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
ask
from cid.contact to delegated-ipfs.devTackles task in #24.