Hey @Mikerah, I’ve also been reading the kad spec, since I’d like to revise it soon and get it merged in. The spec doesn’t currently cover the lack of PING messages, but it’s not just the js implementation; go doesn’t do any pinging either.
The current state of things (in go, I haven’t looked closely enough at js yet) is that peers stay in their k-bucket until they disconnect entirely, at which point they’re removed. If a new peer is discovered, but the k-bucket they belong to is full, the new peer is just dropped without health-checking any existing peers.
There is a form of pruning, but that happens in the connection manager. Basically, when the DHT adds a peer to the routing table, it also tags the connection, which signals the connection manager to keep it alive if possible. If the connection limit is hit, untagged connections will be severed first, but DHT connections will eventually be cut. AFAICT, this is the only way a peer will proactively remove an entry from the routing table.
This is a significant change from Kademlia, and we have an issue in go-libp2p-kad-dht tracking this. My intuition is that this is leading to a brittle routing table with a lot of excess thrashing, but we’ll need to measure to know more.