ipni / index-provider

📢 Index Provider
Other
36 stars 17 forks source link

Replace ProvideBitswap with new API based on IPIP-378 #403

Open lidel opened 1 year ago

lidel commented 1 year ago

@masih filling this as a placeholder, feel free to rephrase this to better reflect what needs to happen.

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.

lidel commented 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).

willscott commented 1 year ago

cc @ischasny

ischasny commented 1 year ago

Hi @lidel - is there an alternative API that we can switch over if ProvideBitswap is removed?

lidel commented 1 year ago

@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)

ischasny commented 1 year ago

@lidel would be great if you keep it for now, until an alternative is available. Thank you!