You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In effort to enable self-hosted deployments, and reduce IPFS ecosystem dependency on cid.contact for DHT proxying purposes, we should expose preexisting routing system from Kubo via /routing/v1 (introduced in IPIP-377) on the same HTTP port we use for /ipns and /ipfs Gateways.
Why
Helia users need to be able to prototype and self-host without reliance on a third-party infrastructure
Routing system is already present in Kubo, and we already expose it over RPC, which makes this is only a "cosmetic" change to expose it using alternative, vendor-agnostic API IPFS community agreed on, and dogfood boxo/http/routing/server library
What
add Gateway.ExposeRoutingAPI (Flag, disabled by default for now, we can flip the switch in the future)
make it expose /routing/v1 from IPIP-337 (application/json), equivalent of ipfs routing findprovs
Checklist
Description
In effort to enable self-hosted deployments, and reduce IPFS ecosystem dependency on cid.contact for DHT proxying purposes, we should expose preexisting routing system from Kubo via
/routing/v1
(introduced in IPIP-377) on the same HTTP port we use for/ipns
and/ipfs
Gateways.Why
What
Gateway.ExposeRoutingAPI
(Flag, disabled by default for now, we can flip the switch in the future)/routing/v1
from IPIP-337 (application/json
), equivalent ofipfs routing findprovs
application/x-ndjson
) (IPIP to be written, code in feat: update boxo with routing streaming #9868 and tests wip Missing tests for streaming /routing/v1 #9873)The text was updated successfully, but these errors were encountered: