Just been digging through the libp2p datastore thing, and there is a Badger one available, and for some strange reason it doesn't seem to be popular among libp2p users to persist network state data.

Or they are using their own gossip system instead of saving the effort and using the decently effective one in libp2p, that is why ipfs pages only take a second or two more than normal pages to find and retrieve.

They were good enough to expose the underlying `badger.DB` type, which I have had a little experience with. I needed to be able to scan these damn things, not just fetch them on requests from other places that had cached the relevant key for the entry.

As such it's no bleedin wonder nobody uses it, you can't have a table without the ability to walk through it, and because hash values are random, it is random.

Walking key value tables is the very basis of the endlessly irritating map/reduce features many OOP languages have in their maps. Well, they don't anyway translate efficiently to key value stores.

The get/put functions iterate the keys, but this operation is buried under about 3 layers of type indirection.

If you are to write any other kind of search than straight key retrieval you need a filter function and run that inside a read only view iterator for the table.

It would have been easy for the libp2p people to make a sane kv table access API but they didn't and now they won't because surprisingly nobody uses one that gives you no stinkin iterator.