-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
HTTP Router only uses Addresses.Swarm #9823
Comments
@jtsmedley where Routing v1 HTTP endpoint are you using? Are you trying to put provider records over HTTP or only receive them? |
@aschmahmann This issue occurs is related to publishing provider records over HTTP from Kubo. The Routing v1 HTTP request that is emitted by Kubo contains a list of addresses that is different than the list of addresses being published by the DHT publisher. |
Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 7 days. |
@jtsmedley afaik PUTs to The fix for this needs to wait until IPIP-378 is finalized and implemented in boxo/routing/http, unless you have time to debug and submit a PR with surgical fix. |
@lidel To be clear this issue is with Kubo Delegated Routing posting to Index-Provider. This is not an issue with posting into Kubo. I consider Kubo's IPNI put implementation to currently be broken and cannot use it. |
Correct, you can't use it: PUT to
We've just started working towards making @jtsmedley It sounds like you are using experimental PUT code against your own endpoint, and it happens to work aside from the Why were you under impression PUTs are supported? |
@lidel I do see here that v0.18.0 support is just for GET. I believe this got confusing with the deprecation of Reframe which dropped the original buggy but deemed production worthy path of onboarding advertisements from Kubo onto IPNI. That left only experimental PUT code from Kubo to work with the index-provider which would otherwise basically be a dead project which has resulted in this documentation being developed out of positive intent. I think the answer here is that officially Kubo doesn't support PUT for Delegated Routing, but has experimental support currently that has known bugs. I am happy with that answer and can only give a thumbs up in support of Kubo being able to PUT to IPNI in some way. |
Thank you, @jtsmedley, this clears a lot of confusion. 🙏 Since it was the IPNI project who did not test this end-to-end, but prompted you to use it before it's ready (IPIP-378 is wip), you could fill an issue in ipni/index-provider and ask them to either provide support and contribute bugfixes, or remove it from docs until it is safe to recommend. Kubo maintainers will not spend time on this until officially supported, the spec is finalized and tests are in place. |
Triage notes:
|
Checklist
Installation method
ipfs-update or dist.ipfs.tech
Version
Config
Description
When using an HTTP router Kubo uses the config information from
.Addresses.Swarm
rather than addresses parsed from.Addresses.Announce
which is what is consistently used for DHT announcements.Possible Affected Code: https://github.com/ipfs/kubo/blob/master/routing/delegated.go#L202
--- HTTP Routing Payload [Actual]
{ "Providers": [ { "Protocol": "transport-bitswap", "Schema": "bitswap", "Signature": "mglKVuUbSEZ45gQRS1is1CHhHQY7B1c+Zu39jXUM1zG4JNJyDczHgKpdNMZ7meFccy8MrIlXfReudSz3vD6+BCg", "Payload": { "Keys": [ "[CONTENT_ID]" ], "Timestamp": 1681748062739, "AdvisoryTTL": 86400000000000, "ID": "[KUBO_ID]", "Addrs": [ "/ip4/0.0.0.0/tcp/4001" ] } } ] }
--- HTTP Routing Payload [Expected]
{ "Providers": [ { "Protocol": "transport-bitswap", "Schema": "bitswap", "Signature": "mglKVuUbSEZ45gQRS1is1CHhHQY7B1c+Zu39jXUM1zG4JNJyDczHgKpdNMZ7meFccy8MrIlXfReudSz3vD6+BCg", "Payload": { "Keys": [ "[CONTENT_ID]" ], "Timestamp": 1681748062739, "AdvisoryTTL": 86400000000000, "ID": "[KUBO_ID]", "Addrs": [ "/ip4/[PUBLIC_IP]/tcp/4001" ] } } ] }
The text was updated successfully, but these errors were encountered: