Delegated Routing: How Light Clients Skip Running a DHT

IPFS delegated routing exists because this series' own DHT coverage has an unstated assumption baked into it: running a full DHT client, dialing peers, walking the address space, maintaining routing tables, is real, ongoing work, and a browser tab or a resource-constrained device can't reasonably do it. Delegated routing is how a light client gets the same answers, who has this CID, where is this peer, what does this IPNS name resolve to, without becoming a DHT participant itself.

TL;DR:

• The Delegated Routing V1 HTTP API defines plain HTTP endpoints for the same questions a DHT lookup answers: GET /routing/v1/providers/{cid}, /peers/{peer-id}, and /ipns/{name}, so a client gets JSON back instead of running its own peer-to-peer lookup
• someguy is the reference delegated routing server; it proxies incoming requests to the Amino DHT and to a separate system, the Network Indexer, rather than running a routing system of its own
• The Network Indexer (also called IPNI, reachable publicly at cid.contact) is architecturally different from the DHT: providers push advertisements to it directly instead of peers discovering records through Kademlia-style distributed lookups
• A real, measured 2025 update to someguy added address caching that eliminated about 83% of additional peer-lookup requests and cut P95 latency from 1.91s to 1.35s, a concrete case of what delegated routing infrastructure improvements actually buy
• This is exactly the mechanism a browser-based Helia node relies on for practical routing, and it's a different, earlier-stage shortcut than AIOZ Pin's gateways, which skip routing and discovery entirely rather than delegating it to a faster HTTP call

Why a Light Client Can't Just Run the DHT

This series' DHT article describes a real, ongoing job: maintaining connections to enough peers, running Kademlia lookups, keeping a routing table current. That's reasonable for a server-class node that stays online continuously. It's a poor fit for a browser tab that exists for one page load, or a mobile app that can't keep dozens of persistent peer connections open in the background. Delegated routing exists specifically to give that kind of light client the DHT's answers without the DHT's ongoing cost.

The V1 HTTP API: The Same Questions, Over Plain HTTP

The Delegated Routing V1 API defines a small set of endpoints answering exactly the questions this series' DHT and IPNS articles already cover. GET /routing/v1/providers/{cid} returns peer records for whoever's advertising a given CID, the HTTP equivalent of a DHT provider lookup. GET /routing/v1/peers/{peer-id} resolves a peer's known addresses. GET /routing/v1/ipns/{name} resolves an IPNS name to its current record, with a corresponding PUT for publishing updates. Requests and responses are ordinary JSON, multibase-encoded CIDs, string-encoded multiaddrs, with standard HTTP caching headers and support for streaming large result sets. A client calling these endpoints never opens a libp2p connection or runs a Kademlia walk itself; it just makes an HTTP request and gets an answer back.

someguy: The Reference Server Behind the API

someguy is the reference implementation of a delegated routing server, and its own job is instructive: it doesn't run a routing system of its own so much as proxy incoming requests to two separate backends, the Amino DHT (the same DHT this series already covers) and a second, architecturally distinct system called the Network Indexer. The IPFS Foundation runs a public instance at delegated-ipfs.dev/routing/v1, which is what a Helia node or any other delegated-routing-aware client typically points at by default.

The Network Indexer: A Different Shape of Routing

The Network Indexer, also called IPNI and reachable publicly at cid.contact, solves the same underlying problem, mapping content to providers, through a structurally different mechanism than the DHT. Rather than peers discovering each other's provider records through distributed Kademlia lookups, providers push signed advertisements directly to the indexer, chained together the way each advertisement links to the previous one, and the indexer ingests and stores the resulting CID-to-provider mappings directly. A lookup against the indexer is a direct query against that stored index, not a multi-hop peer-to-peer walk. This makes it a genuinely different routing backend, not just a cached mirror of the DHT, which is exactly why someguy queries both rather than treating either as sufficient on its own.

A Real, Measured Performance Improvement

It's worth grounding this in something more concrete than the general shape of the architecture. A 2025 update to someguy (v0.7.0) added an address cache, up to a million peer addresses held for 48 hours, along with background probing that periodically re-verifies which cached peers are actually still reachable. The measured result: for the roughly one-third of requests that needed address resolution at all, about 83% were served from cache instead of triggering a fresh lookup, and P95 latency for successful responses dropped from 1.91 seconds to 1.35 seconds, a 560-millisecond, 29% improvement. That's a genuine case of delegated-routing-side infrastructure work translating directly into faster answers for every light client relying on it, without any of those clients changing anything on their end.

Where This Fits an AIOZ Pin Workflow

Delegated routing is exactly the mechanism a browser-based Helia node, covered elsewhere in this series, relies on for practical content and peer discovery, since running a full DHT client in a browser tab isn't realistic. It's worth being precise about how this differs from AIOZ Pin's own gateway shortcut, covered throughout this series: delegated routing still answers the same discovery question the DHT would, just faster and over HTTP instead of peer-to-peer; a gateway request skips the discovery question entirely, since the gateway already is a known, reachable host. Both are ways of avoiding the cost of a full DHT lookup, they just remove different amounts of work.

Frequently Asked Questions

What is delegated routing in IPFS? A way for a light client to get DHT-equivalent answers, who has this CID, what does this IPNS name resolve to, over plain HTTP instead of running its own DHT lookups.

What is someguy? The reference delegated routing server. It proxies incoming HTTP requests to the Amino DHT and to the separate Network Indexer, rather than running its own routing system.

What is the Network Indexer? Also called IPNI, reachable at cid.contact: a routing backend where providers push signed advertisements directly rather than peers discovering records through DHT-style distributed lookups.

Why can't a browser just run a full DHT client? Maintaining DHT connections and routing tables is ongoing background work unsuited to a browser tab's lifecycle. Delegated routing gets the same answers without that ongoing cost.

Did a real update actually improve delegated routing performance? Yes. A 2025 caching update to someguy eliminated about 83% of additional peer-lookup requests and cut P95 latency from 1.91s to 1.35s, a measured, documented improvement.

Does AIOZ Pin's gateway use delegated routing? A gateway request skips content and peer discovery entirely, since the gateway already holds the content. Delegated routing is a different shortcut, still answering the discovery question, just faster than a full DHT lookup.

Related Reading

• How IPFS Finds and Retrieves Your Files: DHT Provider Records and Bitswap Explained - the full peer-to-peer lookup process delegated routing offers a lighter-weight alternative to
• Helia: IPFS's Modern JavaScript Implementation - the browser-targeted implementation that relies on delegated routing in practice
• IPNS: Mutable Pointers to Immutable IPFS Content - the naming records delegated routing's /ipns/{name} endpoint resolves
• ipfs:// in the Browser: How It Actually Works - the broader browser-support gap this lighter-weight routing option is part of closing

References

• IPFS Docs: Nodes
• IPFS Specs: Delegated Routing V1 HTTP API
• IPFS Blog: Faster Peer-to-Peer Retrieval in Browsers With Caching in the Delegated Routing HTTP Server