Open lidel opened 1 year ago
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 ProvideBitswap
now, or should we avoid making waves and keep code in Kubo as-is until IPIP-378 is ready as replacement?
Asking because https://github.com/ipni/index-provider/#configuring-kubo-to-advertise-content-onto-ipni-experimental still points your users towards the ProvideBitswap
(unsupported API).
cc @ischasny
Hi @lidel - is there an alternative API that we can switch over if ProvideBitswap
is removed?
@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 https://github.com/ipfs/specs/pull/378#issuecomment-1749309608).
(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
: https://github.com/ipfs/boxo/pull/422#discussion_r1300722807/routing/v1
: https://github.com/ipfs/specs/pull/378