the8472
commented
2 years ago One immediate way that should be possible is to run a NodeLookup task and have a listener registered with dht.addIncomingMessageListener(). What that you get all incoming messages and can filter those down to find_node responses which match the remote ID you're interested in.
A more targeted way would be adding a similar listener to the lookup task that only gets responses to that task. Or if latency is not a concern then adding a way to extract the closest-set when a lookup has finished.
And indeed, I do not intend to support controlling the node ID because it's supposed to be random and may be further constrained by BEP 42 or similar future extensions. And also because people "doing clever things with node IDs" often tend to do malicious things. I acknowledge that a node ID generated through proper cryptographic means and not mined for specific prefixes is in principle fine but there's no agreed-on standard for that that I could just implement in the library to avoid offering a generic setter. I can't stop you from maintaining a patch of course.
zapek
I'm working on Xeres which is a reimplementation of Retroshare, a decentralized peer to peer app to chat, exchange files and so on.
To facilitate finding its known peers, Retroshare uses the mainline DHT. But it doesn't store anything in it. It works like that:
Basically it doesn't use get_peers nor announce_peer.
While I managed to integrate mldht into Xeres (here) and it works for storing and retrieving "the bittorrent way", I'm struggling to find a way to make it compatible with Retroshare.
I'm aware of this issue so I would have to find a way to set the node id myself. But how do you find a node? I see there's a NodeLookup task but it's not exactly like PeerLookupTask as it doesn't seem to have a listener for the result.
Is the above use-case possible at all with mldht?