ipni / caskadht Goto Github PK

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 😅.

flushes will be relatively expensive. we should understand how many packets we're potentially sharding a respond into and try hard to minimize it.

Originally posted by @willscott in #5 (comment)

the current running instance is not reliably serving results quickly due to resource limitations.

Would be great to brainstorm suggestions to do better in the next days.

One naive thought from perspective is to partition instances of this pod by keyspace, such that queries go to one of the multiple replicas, and that replica only needs to stay connected / track a portion of the overall dht peers.

I understand that one of the nice aspects of ndjson is streaming capability, but when reading this line below the README, I was curious what an example response might look like with ndjson and how it will differ from regular JSON (since with ndjson every line still needs to be valid json)

steams the results back over ndjson whenever the request Accepts it or regular JSON otherwise.

Expose HTTP endpoint that given a peer ID , it returns a list of addresses for it.

Note, this requires specification on both IPNI and HTTP delegated routing.

Relates to #9