Switch to public/private keys instead of shared password?

[nictuku]

Right now, wherez works as p2p: clients behave more or less like servers, except that they can optionally decide to not announce themselves (by passing a negative port number).

But it uses a single password, and the client needs that password to find the servers.

That works fine when the application owner trusts the client running wherez on the other side, which covers many use cases. But I expect people to have other use cases too.

This issue is for tracking user interest on such a change. If you care about this, please weight in.

[spikebike]

I thing it would be awesome if a wherez became a useful peer
introduction service available to all p2p systems speaking any protocol.

Mainline DHT is close to useful as is, but approximately 100% of
existing peers are bittorrent clients or fake peers. These fake peers
claim to be a peer for any queried infohash. I'm guessing they are
looking to search/index torrents, DoS the DHT, DoS a tracker, or file a
copyright infringement lawsuit. Thus the need for wherez or similar
peer introduction service.

To support peer introductions for different protocols/p2p apps there
should be a way for peers of a certain type/protocol to find each other.
My thinking was more along the lines of an ApplicationID instead of a
passphrase, but the functionality is similar.

So to thwart current and future evil nodes that claim to be peers for
all protocols/infohashes we need a way to verify an ApplicationID
without revealing it.

Does the current passphrase/verifyPeer reveal (in either direction) the
passphrase?

Seems pretty universal on bittorrent clients to have an auto blacklist
feature. I'm guessing it's just publishing random infohashes and
blacklisting any nodes that claim to be peers or connect with a magnet
URI to attempt a .torrent download.