-
Notifications
You must be signed in to change notification settings - Fork 17
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
Replace ProvideBitswap with new API based on IPIP-378 #403
Comments
Hi, checking in again.
@masih @willscott Do you have an alternative way of serving your users now, since we've talked about this last time? Is it safe to remove Asking because https://github.com/ipni/index-provider/#configuring-kubo-to-advertise-content-onto-ipni-experimental still points your users towards the |
cc @ischasny |
Hi @lidel - is there an alternative API that we can switch over if |
@ischasny we want to define one in IPIP-378 and implement that in Kubo and Boxo, but it had no engagement for a while (see question ipfs/specs#378 (comment)). (Ok if you say "keep old thing for now", just planning Q4 and wondering if we could do cleanup now, before IPIP, or after, in 2024) |
@lidel would be great if you keep it for now, until an alternative is available. Thank you! |
This project depends on undocumented and deprecated
ProvideBitswap
from boxo.IPFS ecosystem is shifting towards nodes having both HTTP and Bitswap as retrieval protocols, and we would like to avoid separate announcement for each protocol.
IPIP-378 aims to introduce a specification for how provider PUTs are expected to work in cases when CID is provided over more than just bitswap
Once we have that, projects like this one should stop using
ProvideBitswap
and switch to the new API based on IPIP-378.Ref.
ProvideBitswap
: feat(routing/http)!: delegated peer routing server and client, IPIP 417 ipfs/boxo#422 (comment)/routing/v1
: IPIP-378: Delegated Routing HTTP POST API ipfs/specs#378The text was updated successfully, but these errors were encountered: