btoms20
commented
1 year ago The part I wanted to focus on the most was actually key formation. When I first began interacting with the dht I naively converted the entire string '/pk/Qm...' directly into bytes. It took me a few hours to figure out you convert the namespace into bytes and append the original PeerID bytes to it. Pretty silly mistake but thought it might be helpful to jot down for others.
I agree that this probably belongs somewhere in the ipfs docs.
This PR adds a Practical Example section to the Spec in an attempt to help developers (and end users) understand how the default IPFS Kad DHT works and how Keys on the DHT are derived for various namespaces.
What?
A brief example of how to format an RPCMessage in order to query the default IPFS Kad DHT for the PublicKey Record of the Bootstrap node with PeerID
QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ.Why?
No matter how well a Spec is written I often find myself searching for an example with real data. Real data, in this case, is hard due to the ephemeral nature of the DHT, but assuming the Bootstrap node used in this example persists, the querying of it for its PublicKey Record should continue to work.
More?
Hopefully we can add more examples to this section going forward. Maybe a similar example searching the
ipnsnamespace and/or searching the KadDHT for Content Providers.Future
If the community thinks these Practical Example sections are worthwhile / helpful, we could add relevant examples to the rest of the Specs.
Notes
detailstag that defaults to closed as to not clutter the page. At the end of the day this is a Specs documentation and it should remain clear and concise, but if an implementer gets stuck, they could always dig deeper into the examples. Hopefully this doesn't break any formatting rules.Thanks