Matt Joiner

I think #283 should be done first, as it may affect what information needs to be persisted.

#283 also makes reconstituting a routing table more robust. Currently if we did this, we'd have to connect to each peer added to maintain the routing table invariant that all...

I'm suggesting, more or less: ``` IpfsDHT.SetRoutingTable([]PeerInfo) IpfsDHT.GetRoutingTable() []PeerInfo ``` All other behaviours at the whim of the consumer.

Thanks @stefanhans, that's good to see. I'm working on something similar, please report any findings or stumbling blocks you have as this kind of tool should be possible.

@stefanhans If it interests you, have a look at https://github.com/libp2p/go-libp2p-kad-dht/tree/dht-cmd, in `./cmd/dht-tool` (inconsistent naming ftw).

@raulk What API stability guarantees do we want to make regarding this? Should there be new methods for things that expose stats?

I think this issue is too general. > * What addresses of mine are stored in the DHT? Are they as expected? This can be done with a query to...

Can we close this and create a metrics label? Super issues are too fluffy and conversation will be interleaved across different metrics.

All the metrics stuff can be addressed by #252, #300, and #297.

A list of metrics is tracked in #304.