Trustless single-request resolution of recursive/delegated IPNS chains (return the traversed IPNS records + final content)
- Dominant language
- Go
- Stars
- 17.1k
- Forks
- 3.2k
- Avg merge
- 3d 18h
- Merged PRs (30d)
- 11
Description
**Context.** I resolve "delegated" IPNS chains where one IPNS record points to another IPNS name before reaching content: `/ipns/An → /ipns/Mn → /ipfs/`. 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/?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/` chain in one round-trip rather than `N+1`.
Thanks!
Contributor guide
Research direction
Start by reviewing Kubo's gateway handling of recursive IPNS resolution, the ?format=ipns-record and ?format=car responses, and the X-Ipfs-Path/X-Ipfs-Roots metadata mentioned in the issue. Define and test a single-request response that preserves the ordered signed IPNS records and final content or CID so a trustless client can verify every hop.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100