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
initflag 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.