Experimental features should graduate some day

Help Kubo
1

Seeing the deprecation of Pubsub reminded me how there are actually critical Kubo features that have been marked as experimental for years.

I think some of these should graduate because they are de-facto in production, and they would be more in production if the documentation wasn’t warning against them:

  • Raw leaves for unixfs files: even if not enabled by default, it should not be called experimental, just like CIDv1 is not.
  • Private Networks: I’m not even sure why it says it needs more documentation. Certainly more UX (like having a command or an init flag is not much work. pnets are widely used.
  • Plugins: the roadmap is too demanding since it does not even depend on Kubo. No one is going to invest in making plugins seriously if Kubo can come and decide one day that this won’t be a thing.
  • Directory sharding / HAMT: this is now default? Why is it marked as experimental?
  • AutoRelay: If we have relay v2, can we remove this from the experimental feature list? Isn’t relay v2 hole punching a code that is meant to stay even if not enabled by default?
  • Graphsync: I don’t quite understand that “next-gen graph exchange” is already dead.
  • Noise: it is not experimental, enabled by default
  • Accelerated DHT client: used anywhere where there is more than a trivial amount of CIDs needed to be annouced to the DHT. Is there a commitment to support this?

I don’t think it does Kubo a favor when some critical functionality is marked as experimental for years. The roadmaps for experimental items could also apply to unixfs, bitswap and other forever-in-progress components of the stack. i.e. shouldn’t we be sure that you cannot use Unixfs for DDoS before consider it stable? Yet it is NOT experimental.

Maintaining these things will costs the same as both experimental or not (how much it costs depends on how much space they can take on the roadmap), so it is more about publicly acknowledging that certain features are important/core and people can rely on them to build things as they are now.

4 Likes
2

+1 makes perfect sense.

3

Agreed 100%, the Kubo maintainers also have consensus that we should have a “graduate or GTFO” policy for experimental features. We are already acting on this, we will be “graduating” the accelerated DHT client imminently (see Move AcceleratedDHTClient from being experimental · Issue #9703 · ipfs/kubo · GitHub).

Thank you for this list, I’ve added these to Cleanup Experimental Features · Issue #9396 · ipfs/kubo · GitHub. Some of this is just docs cleanup.

4 Likes
4

:+1: it should be default, we just gonna have some peoples complains hashes are different so we need to do it once for good (bundle it with other hash breaking stuff).

This is more a libp2p thing, AFAIT it is not in a good light because QUIC is being put more and more in front and it does not support PNET yet, and I havn’t seen anything indicating support would be added.

I’m pretty sure that default now.

I want to remove it, no one ever wrote code to leverage this in Kubo or anywhere (/ code that would use graphsync to download from Kubo nodes).
Adding the server is the easy thing because you can just wire it up to the blockstore, the hard thing is to add the client because you need to rewrite a good bit of code to be ipld-prime & selectors compatible (most of kubo is not).

That not experimental, AFAIT the docs/experimental-features.md file was written as an history of all the experimental features.
Seems like you want us to clean up that file, probably a good thing to do.

I’m working on making it not experimental for Kubo 0.20: Move AcceleratedDHTClient from being experimental · Issue #9703 · ipfs/kubo · GitHub