IPIP-0476: Delegated Routing DHT Closest Peers API

[achingbrain]

Adds a new HTTP endpoint that can be used to request records for the closest peers to a given key that the routing implementation knows about.

The use-case for this is browser nodes performing random walks to find peers that they can make a circuit relay reservation on, without having to be DHT clients to perform the walk which can be undesirable given all the connection/processing overhead that entails.

I've tried to avoid defining what "closest" means to leave it up to the routing implementation, only that the responses should be "closer" than the optional closerThan parameter which should mean the caller gets useful results for other scenarios.

[SgtPooki]

Just connecting some dots. This problem this solves seems somewhat related to https://github.com/libp2p/specs/issues/222

[achingbrain]

Refs https://github.com/ipshipyard/roadmaps/issues/16

[github-actions[bot]]

🚀 Build Preview on IPFS ready

• 🔎 Commit: d551c94c069d7d406a407809c0d2d8603fdb8a34
• 🔏 CID bafybeiaybdf53eohqwjecfa6e6hb3adqbyidq2quom3bwkgcizl5blh4aa
• 📦 Preview:
  • dweb.link
  • w3s.link
  • inbrowser.link

[lidel]

@achingbrain FYSA to make this bit more formal, generated IPIP-0476 documenting why we need this: it includes the motivation from the PR (browser nodes needing lightweight peer discovery), the specification, rationale, and future-proofing considerations discussed in the PR comments.

Feel free to add any context to the document you find useful.