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/DELEGATE_ROUTERS.md at master · ipfs/js-ipfs · GitHub)
Awesome! This is really helpful!
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 "https://node0.delegate.ipfs.io/api/v0/dht/findprovs?arg=<hash>&verbose=false"
You will get the addresses directly as a bonus.
See the documentation accordingly: HTTP API | IPFS Docs
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.
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.
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).
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).
I found the enum that allows to determine the Type of the response of the HTTP API, there it is:
And for the CLI:
You guys are so awesome! Thank you so much for this help!