Closed l0k18 closed 1 year ago
Basic access to the peerstore metadata now available via the badger DB interface and peer records counted in the test.
Iterating through the records it was discovered that the host is storing its own private key in this database, and it's done right at the beginning of initialising it.
This obviously has to be fixed.
Commit has been squashed into one, the unsquashed one forked beforehand to peerstore_unsquashed branch.
All tests passing on this branch, there is related things that need to done yet but this completes what should be all of the basic features as checked off in the initial post.
@lyowhs pls review, comment and let's get this into the master branch.
merging up, need to get to issues that overlap this
Implementing the gossip and persisting of network information to speed up client connection at startup.
Several items involved here:
pstoremem
andpstoreds
packages from libp2p as it is slated for removal, as it is a virtually useless API for any purpose anyway. Better solutions should be built later, for now this is expedient.badger.Datastore
's exposedbadger.DB
where all the usual K/V functionality is available.- [ ] Use new iteration facility to implement storage of peer node's measured metadata, ban scores, times detected as being unexpectedly offline or unresponsive, geoip data, anything, in a persistent way also keyed to the public identity key. Needs also some kind of TTL to purge if it drops offline for a long time (month?).todo: Setting this database to have the key store live in memory will make very fast searches when memory is available, enabling fast access to keys via their public keys. Initial attempts to enable this triggered an error regarding the value journal size, for later work as part of a "use lots of memory" option for high throughput systems. To be precise it was setting the key log to be memory mapped. Maybe a permissions problem?