FindPeer Design Review

There are a few upcoming changes to the DHT and we'd like to nail down what the contract and expectations are for the FindPeer query to make sure they are met from a performance and security standpoint without adding too much complexity.

Questions for the upcoming design review include:

• Do we want FindPeer or ConnectPeer? Do we really want the address or just a connection?
• Should we run a full query looking for the target peer's addresses, or be async/allow early aborting if we find a single address?
  • Full query could be running GetClosestPeers(target) and then asking them each for the addresses they know about
  • Aborting early just stops once we get a single address
  • If doing async do we continue the query while we're trying to verify the address, or pause?
• Do we want peers behind NATs advertising their addresses in the DHT?
  • Relates to #779

Existing implementation approaches

Current go-libp2p-kad-dht approach:

• Return multiaddrs
• Return as soon as we find a single address for the target peer
  • Should be a good address since peers should only return addresses of peers they are connected to
• Records are not signed and we could be told any address at all
  • Could be resolved once #776 lands

libp2p/go-libp2p-kad-dht#436:

• Connect to the peer we're looking for
• Return once we've connected to the peer
  • Query continues up until we've connected to the peer
  • If a particular dial to the target peer fails, we'll try again if we learn about them again through the query
    • Having address (instead of peerID) based backoff in the dialer would help here (although it could be handled within Kad if needed)

No files or tests are named. Start by reviewing the current go-libp2p-kad-dht FindPeer approach, libp2p/go-libp2p-kad-dht#436, and related issues #779 and #776; done means agreeing on the FindPeer or ConnectPeer contract, query behavior, address handling, and security expectations.