Open lidel opened 1 year ago
This is great! Am I understanding correctly from your second initial note that you expect a car to contain only ever one IPNS node? (I’m wondering why “at beginning” is important)
@jphastings these details are highly tbd. We may punt this until we have something like "content path aware CARv3".
If one would want to implement PoC today, they would want ipns-record(s) first in the stream, so the client can fail-fast if none of records is valid (performing signature check from IPNS spec + picking ipns record with highest sequence number if there is more than one). There is no point in parsing blocks for root CID if IPNS→CID mapping is not verified.
My original reply collapsed; it was based on a misunderstanding!
@jphastings - if i ask for a car representing 'domain.com', and i get back an IPNS record of 'domain.com' pointing to a CID, and then the contents of the CID, then i should be cautious about rendering the CID if i can't validate the IPNS record.
@lidel - I'm curious what you see as requiring a bump of format to "CARv3" vs using the multicodec for IPNS and including such IPNS blocks within the existing car wrapper?
@willscott my mistake, I misinterpreted @lidel’s comment as implying only one IPNS record per CAR, but on re-reading I can see that’s not the case — thanks for helping me spot that!
IPIP-351: IPNS Signed Records Response Format on HTTP Gateways will return a raw IPNS record, allowing a custom light client to verify IPNS without having to run DHT client.
Users asked for the ability to export both CIDs and IPNS record into a CAR, transport over sneakernet and load this on airgapped node, which is a good use case.
Another use case is Decentralized Gateway WG, which could benefit from the ability to have a single round-trip that includes full or partial CAR with content + ipns-record.
Broad strokes UX we want to accommodate:
Initial notes / subtasks
cc @hacdias (for now just fyi, tbd if this is something we need to prioritize for Saturn work any time soon)