IPNS resolution: V2-only records

[lidel]

Writing this down, as there is a lot of confusion in ecosystem around this atm, the goal of this issue is to be useful reference while we clean this up.

There are two ways of getting a signed IPNS record over HTTP:

• GET /ipns/{id} with ?format=ipns-record or Accept: application/vnd.ipfs.ipns-record to trustless gateway that supports IPIP-0379: Delegated IPNS HTTP API
  • This is something this project MUST support out of the box
• GET /routing/v1/ipns/{id} to HTTP routing service that implements IPIP-0351: IPNS Signed Records Response Format on HTTP Gateways
  • This is something we MAY add in the future, once ecosystem figures out how to make HTTP first-class citizen, and how to have HTTP endpoints announced in places like IPNI and DHT
  • We most likely will expose a "public good" HTTP/DNS endpoint that acts as a caching proxy for IPNI/DHT but details tbd (bifrost-infra#2142)

For the record, there is also legacy Kubo RPC:

• POST /api/v0/dht/get?arg=/ipns/{id} this SHOULD NOT be used.
  • This is legacy we want to deprecate, it does not support HTTP Caching and requires additional decoding of results to find final value.
  • See bifrost-gateway: Remove dependency on Kubo RPC and node[0-2].delegate.ipfs.io

[lidel]

@John-LittleBearLabs iirc ipfs-chromium currently uses the Kubo RPC? Or did we switch to application/vnd.ipfs.ipns-record on gateways? (it was not supported when this project started, but it is now, at least at ipfs.io one)

[John-LittleBearLabs]

Kubo RPC? Or did we switch to application/vnd.ipfs.ipns-record on gateways? (it was not supported when this project started, but it is now, at least at ipfs.io one)

The latter: ipns/{id}?format=ipns-record

There was a short time at the beginning of the project where it was understood this was coming, but wasn't yet released. At that early phase this simply wasn't trustless for IPNS URLs - was just forwarding them as-is to a Kubo gateway.

[lidel]

Ack, in that case I think we are mostly done, only remainign thign around IPNS is to ensure wait for https://github.com/ipfs/specs/issues/376 and then revisit this issue to make sure we interpret both V1+V2 and V2-only records as valid.

[lidel]

Update: IPIP-428 landed, it includes IPNS Records that can act as test vectors (both positive and negative): https://specs.ipfs.tech/ipips/ipip-0428/#test-fixtures

I think for this project, tldr is making sure we implement the updated "Record Verification" section at https://specs.ipfs.tech/ipns/ipns-record/#record-verification + do the right thing for the mentioned test vectors.