Closed jannikluhn closed 4 years ago
One thing I had thought of was exposing some of this discovery data over JSON-RPC to make it a little easier to introspect and debug at runtime. We'll end up with application logic that publishes records and holds onto other node records and being able to explore and dig into this data at runtime without restarting the services could be very valuable. No need to prioritize this up-front but maybe something to think about as you get closer to a live working implementation and start wanting to see what's happening under the hood.
Also, do you have a rough ETA on when this will be usable? How long until we could run trinity as a bootnode for v5 discovery and actually do the node-finding for a specific topic.
cc @carver as this might be a good way for trinity nodes to find other trinity nodes were we to do something for beam sync such as a new subprotocol for nodes to gossip around block proofs or even just a firehose sub-proto to speed up the state fetch using better mechanisms.
Also, do you have a rough ETA on when this will be usable? How long until we could run trinity as a bootnode for v5 discovery and actually do the node-finding for a specific topic.
Originally, the plan was to have a working version at the end of this month. This still seems realistic for the plain DHT implementation, but not for topic discovery. However, if we want to, we can parallelize the work a little as the DHT and especially topic discovery are somewhat independent from the details of the lower layers I'm working on right now. I've opened two issues for those.
Main PRs
Secondary PRs
Symbols
:question: to do :construction: WIP PR :eyes: ready for/under review :heavy_check_mark: merged