No multiaddrs returned from provider record lookups #9
Description
At the moment neither IPNI nor ipfs/specs#337 support peer record lookups. This means that, assuming no external discovery mechanisms, a peer that relies on this repo for finding a libp2p peer to talk to is going to have a bad time.
While it would be totally reasonable to think because the content routing interface returns a peer.AddrInfo that it has addresses and you can just pass it right along. Unfortunately, this is not the case. Most DHT server nodes only keep the peer record around and while they'll tell you the multiaddrs for that peer if they know them they may not have them. This is to deal with the fact that, unlike say Filecoin SPs, many clients of the IPFS Public DHT have non-stable IP addresses and so it wouldn't be reasonable to store those addresses for 24 (now 48) hours.
There are two ways to resolve this issue:
- When you get a peerID without any addresses do a
FindPeerto connect to the peer and get their addresses (you can just pull them out of the peerstore)- You can use caching here to save on these extra connections. IIRC go-libp2p's peerstore will already do some caching for you here so you can probably pull addresses out of the peerstore if they're there and search otherwise.
- Expose a FindPeer HTTP endpoint that nodes can call
I suspect that ultimately we will want both 1+2 and that 1 is the option that will move things along faster.
Note: I apologize for not having done this for you in someguy and even more for not having filed the issue on someguy for discovery purposes. I was expecting to tackle this either when routing.delegate.ipfs.io became a production service and/or when option 2 happened, but neither have occurred yet so here we are 😅.