Trustless single-request resolution of recursive/delegated IPNS chains (return the traversed IPNS records + final content)

[Rinse12]

Context. I resolve "delegated" IPNS chains where one IPNS record points to another IPNS name before reaching content: /ipns/An → /ipns/Mn → /ipfs/<cid>. This keeps an owner key (An) offline while an online delegate re-signs the inner record (Mn). The final content is signed by the terminal key Mn, not by An.

Problem. When loading this over an untrusted gateway, the final content alone is not enough — I must independently verify each hop's signed IPNS record to bind An → … → Mn (otherwise a malicious gateway could serve content under any key and claim it is An's resolution). Today a plain GET /ipns/An makes the gateway recurse internally and returns only the final content; the intermediate signed IPNS records are discarded and exposed in no response header (X-Ipfs-Path / X-Ipfs-Roots only carry the final CID — verified empirically on a 2-hop and a 3-hop chain). So trustless verification currently requires one extra GET /ipns/<name>?format=ipns-record per hop, sequentially — N+1 round-trips instead of 1.

Question / request. Is there an existing or planned way for a single gateway request to return both the ordered chain of signed IPNS records traversed during recursion and the final content (or final CID)? For example: a multi-record ?format=ipns-record response, an extension to ?format=car that includes the IPNS records along the path, or response metadata enumerating the intermediate records. The goal is for a trustless client to verify the whole An → … → Mn → /ipfs/<cid> chain in one round-trip rather than N+1.

Thanks!

[lidel]

You've got this exactly right, and no, there's no way to do it in one request today. The gateway resolves the immutable IPNS name down to a /ipfs/{cid} before it even starts building the CAR, so the IPNS records it walked through are already gone by then, from both the CAR and the headers.

This gap already has a home:

• IPIP: include ipns-record in Gateway CAR responses specs#369, "include ipns-record in Gateway CAR responses." The ?format=car-with-records idea you suggested is its core proposal. Some of the groundwork is done:
  • The ipns-record multicodec (0x0300, Add IPNS Record code multiformats/multicodec#312) was added so a record can sit in a CAR as its own self-describing block.
  • IPIP-351 (IPIP-351: IPNS Signed Records Response Format on HTTP Gateways  specs#351) already gives you a single verifiable record, and IPIP-402 already gives you scoped CARs. A records-in-CAR response is mostly those two combined.

ipfs/specs#369 even raises the two questions that matter for your fail-fast goal: whether the record block(s) come first, so a client can check signatures before hashing any content, and whether the CAR exposes two roots (content + record).

The one thing it doesn't cover is your case. ipfs/specs#369 assumes the single record for the requested name; a delegated chain needs every record along the way, in order. A CAR handles that fine (N record blocks plus the content), but that multi-hop requirement isn't written down there yet.

Where things stand: ipfs/specs#369 has no owner and has been parked since 2023, so nothing is in progress. Moving it forward takes a short IPIP extending the trustless gateway spec, then gateway support in boxo, then kubo. (The code that would change on kubo is BlocksBackend.GetCAR in boxo's gateway/backend_blocks.go; it only ever receives an already-resolved immutable path, which is why the record is gone before the CAR is built.)

In the meantime, the hop-by-hop method you're using is the only verifiable option, and it does work: pull each record with ?format=ipns-record, follow its /ipns/... value to the next hop, repeat to the final /ipfs/{cid}, then fetch the content. It's N+1 sequential requests, capped at 32 hops by default.

Two things would help move it: add your delegated-chain case to ipfs/specs#369 so the multi-record need is captured, and if you'd be up for helping write the IPIP, that's the fastest path forward.