feat: support GetClosesPeers (IPIP-476) and ExposeRoutingAPI by default #10954
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hsanjuan
force-pushed
the
feat/get-closest-peers
branch
from
1d5bc1f to
ded09f5
Compare
hsanjuan
force-pushed
the
feat/get-closest-peers
branch
from
ded09f5 to
5d605bc
Compare
gammazero
approved these changes
Sep 26, 2025
guillaumemichel
requested changes
Sep 26, 2025
This allows Kubo to respond to the GetClosestPeers() http routing v1 endpoint as spec'ed here: ipfs/specs#476 It is based on work from ipfs/boxo#1021 We let IpfsNode implmement the contentRouter.Client interface with the new method. We use our DHTs to get the closest peers. We try to respect the count/closerThan options here. We then trigger FindPeers lookups to fill-in information about the peers (addresses) and return the result. Tests are missing and will come up once discussions around the spec and the boxo pr have settled.
hsanjuan
force-pushed
the
feat/get-closest-peers
branch
from
11f924a to
e55712a
Compare
- only query WAN DHT for dual DHT setups (not LAN) - LAN DHT contains private network peers that should not be exposed via public HTTP Routing API - preallocate records slice for better performance - update to boxo v0.35.1-0.20251017171347-325640119338 fixes conflict resolution and aligns with someguy reference implementation
- change Gateway.ExposeRoutingAPI default to true - enables light clients in browsers to use Kubo Gateway as delegated routing backend - add v0.39 changelog entry highlighting IPIP-476 support
lidel
changed the title
Test GetClosestPeers with all Routing.Type values: - DHT-based types that support it: auto, autoclient, dht, dhtclient - Non-DHT types that don't support it: none, delegated, custom Verify proper error handling when DHT is not available.
kept boxo v0.35.1-0.20251017171347-325640119338 as requested
lidel
reviewed
Oct 18, 2025
Member
There was a problem hiding this comment.
Lgtm – pushed some changes:
- clean up the way things are wired up
- tests for positive and negative scenarios
- flip config flag to expose /routing/v1 by default on gateway port
I'd like to include this in 0.39, but would be good to have second set of eyes from either @hsanjuan or @guillaumemichel
hsanjuan
commented
Oct 20, 2025
Comment on lines
+31
to
+34
| #### Routing V1 HTTP API now exposed by default | ||
|
|
||
| The [Routing V1 HTTP API](https://specs.ipfs.tech/routing/http-routing-v1/) is now exposed by default at `http://127.0.0.1:8080/routing/v1`. This allows light clients in browsers to use Kubo Gateway as a delegated routing backend instead of running a full DHT client. Support for [IPIP-476: Delegated Routing DHT Closest Peers API](https://github.com/ipfs/specs/pull/476) is included. Can be disabled via [`Gateway.ExposeRoutingAPI`](https://github.com/ipfs/kubo/blob/master/docs/config.md#gatewayexposeroutingapi). | ||
|
|
Contributor
Author
There was a problem hiding this comment.
You probably thought of this better, but, assuming someone has exposed the gateway listen address already (:8080), doesn't this inadvertently exposes the routing API to the world?
And, if so, how does this interact with certain gateway options... for example NoFetch means the gateway will not trigger lookups nor fetch any content, but now this API would allow for such lookups to be performed, so it seems a door that was closed is being opened. There are also other gateway options that might make similar considerations.
hsanjuan
commented
Oct 20, 2025
Contributor
Author
|
Thank you @lidel for completing, just left a couple of comments. |
guillaumemichel
approved these changes
Oct 20, 2025
Contributor
guillaumemichel
left a comment
guillaumemichel
left a comment
There was a problem hiding this comment.
Looks good! Just 1 comment/question
Contributor
Author
|
Comments addressed. Updated to master and latest boxo commit. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This allows Kubo to respond to the GetClosestPeers() http routing v1 endpoint as spec'ed here: ipfs/specs#476
It is based on work from ipfs/boxo#1021
We let IpfsNode implmement the contentRouter.Client interface with the new method. We use our DHTs to get the closest peers. We try to respect the count/closerThan options here. We then trigger FindPeers lookups to fill-in information about the peers (addresses) and return the result.
Tests are missing and will come up once discussions around the spec and the boxo pr have settled.
TODO