No multiaddrs returned from provider record lookups

[aschmahmann]

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:

1. When you get a peerID without any addresses do a FindPeer to 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.
2. 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 😅.

[masih]

Many thanks for pointing this out 🙏 I'll get to work in delivering on option 1.

At the moment neither IPNI nor ipfs/specs#337 support peer record lookups

There is cid.contact/providers and cid.contact/providers/<peer-id> but neither of which have been mentioned in the IPNI specification. Perhaps it's time to do so.

[masih]

• Re option 1: Fill missing peer addrs via second lookup #11 should do the trick.
• Re option 2: Reduced the scope of this issue by capturing Expose a FindPeer HTTP endpoint  #10
• Re IPNI spec update, captured Define address discovery specification specs#11
  Many thanks