How to find the trace of all IP addresses accessed on DHT to find record?

Hey everybody! I’m building a 3d globe animation which shows how a CID query you type in makes its way around the world on the DHT. My question is, how do I get a sequential list of all the IP addresses that I accessed in order to ultimately find the record? From there, I can use the IP address to find the peer’s geolocation for the animation. Thanks!

Of course, ipfs dht findprovs in verbose mode, gives you all the Peers you have asked for that CID.
And finally ipfs dht findpeer can give you the multiaddr addresses linked to a PeerID.
So you just have to make a little mix to get what you want.

Btw, I am interested to see the final result


Thanks a lot! I’ll post this project on this website once I’m done!

Just a small clarification, it seems to me that js-ipfs does not support DHT yet, you will probably need a delegated router. (js-ipfs/ at master · ipfs/js-ipfs · GitHub)

1 Like

Awesome! This is really helpful!

1 Like

It seems that findProviders in DelegatedContentRouting does not have the verbose option:

findProviders(key: any, options?: { timeout: number; numProviders: number; }): AsyncIterable<{ id: PeerId; multiaddrs: Multiaddr[]; }>

Will I have to create a go server in order to get a list of the intermediary peers used to find the providers?

Well, you’ll probably have to make your own request to the API. It’s not too hard since it’s just a JSON message with a constant structure, but you have to handle well the stream.
Also, you don’t necessarily need to have your own go-ipfs node, but it is always preferable.

You can test that:
curl -X POST "<hash>&verbose=false"
You will get the addresses directly as a bonus.

See the documentation accordingly: HTTP API | IPFS Docs

1 Like

FindProvs does not return the “hops” that a FindProvs query makes before finding results.

You will need to patch the go-libp2p-kad-dht to expose that information (i.e. every time GetClosestPeers is called) in the way you prefer (i.e. log lines) and build go-ipfs with the patched version and then make your app use that.

I think it is an interesting thing but slightly complex. Also note that there will be multiple paths happening in parallel which can lead to something or not.

1 Like

It clearly does for go-ipfs (using the CLI or the HTTP API).
Here the lines prefixed with (example) :

  • provider are the providers of this CID
  • querying are the DHT requests to the peer
  • dialing peer are the connection attempts to the Peers (that we probably found just before)
  • The answer lines are of the form <PeerID> says use <PeerID...>

So there are all the steps of the search.

1 Like

Indeed, although the debug logs do not include context information of what was being search that triggered the operations, so it might be difficult to map things.

(I confess I had no idea go-ipfs uses a way to watch query events and log them).

1 Like

By “what was being search” did you mean the CID? Or the actual K-Closest Peers? Since this example was the result of ipfs dht findprovs QmXYNebUgLtF7mUX96bDwjc5ideoAZjL8iuaComZcSJBaV -v.
Otherwise you could also link the peer answers and chain them (because you know what peer give you what other peers to dial).

1 Like

I found the enum that allows to determine the Type of the response of the HTTP API, there it is:

And for the CLI:

1 Like

You guys are so awesome! Thank you so much for this help!

1 Like