Closed lidel closed 9 months ago
@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)
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 atipfs.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.
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.
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.
There are two ways of getting a signed IPNS record over HTTP:
GET /ipns/{id}
with?format=ipns-record
orAccept: application/vnd.ipfs.ipns-record
to trustless gateway that supports IPIP-0379: Delegated IPNS HTTP APIGET /routing/v1/ipns/{id}
to HTTP routing service that implements IPIP-0351: IPNS Signed Records Response Format on HTTP GatewaysFor the record, there is also legacy Kubo RPC:
POST /api/v0/dht/get?arg=/ipns/{id}
this SHOULD NOT be used.