Same experience here. Owned both and completely agree.

Code: github.com/guillaumemic...

I recommend using Swiss Topo for planning hikes in Switzerland

DHT identifiers are bytes anyway. The different RPCs give context and disambiguate the identifiers 👍️

@expede.wtf what do you mean by "update CIDs"?If you want to use a generic libp2p DHT (without IPFS), you could just define a new RPC ("feature"), accepting CIDs as input. This sub-DHT would be totally isolated from IPFS (no common "feature"), but you could still use IPFS bootstrapers to join.

There is an ongoing discussion about creating a more stable and reliable sub-DHT https://github.com/ipfs/specs/issues/404

The Composable DHT won't make nodes more stable, but not less stable either. Stability depends on the stability of the evaluated "feature". However, if you need very reliable network, with long lived peers, you would be able to add a new "feature" creating a sub-DHT of very stable nodes.

I can only agree with @jorropo.net

It is opening new doors, and we still need to explore what it can enable. For instance, we could even make IPv4 and IPv6 "features", to allow all nodes to discover all peers they can connect to, and to allow content providers to advertise for both IPv4 and IPv6 clients.

We can imagine that each libp2p protocol can be seen as a distinct "feature". It would make it easier to discover, and talk only with nodes speaking your libp2p protocol

DHT "Protocols" represent sets of DHT "features" that a specific application is using. E.g the IPFS DHT "Protocol" is made up of the IPFS Provider Records, IPNS, and Hole Punching "features".

You can think of a "feature" like a RPC that is not essential for vanilla Kademalia to work, but useful to your application. E.g IPFS Provider Records can be seen as a "feature", because storing and serving IPFS data shouldn't be a requirement for all DHT nodes.

Link to the IPFS Thing 2023 recording on the Composable DHT https://www.youtube.com/watch?v=OHrtv1jz2Jc