[Draft] ENSIP-17: DataURI Format in Contenthash

[0xc0de4c0ffee]

@nick.eth

@raffy

We should update ENSIP-7 to include all the known protocols. We should include examples of how you decode and query the data, links to documentation, etc. For the CID examples, we should also put conditionals on the CID codec types. Like what happens if you get a IPFS CID that isn’t a dag-pb? Or an IPNS CID that isn’t a libp2p-key? I can do this if appropriate.

Good idea. If you’re happy to take it on, that’d be much appreciated!

+1 for expanding docs with examples. We can help around with fancy CIDs

IPFS:
There’s no need to add “conditional” for different codecs. eg, dag-json, dag-cbor or even raw codecs are already prefixed with IPFS namespace and auto handled by IPFS gateways. There are tons of other codecs “not-implemented” by ipfs gateways that mostlikely won’t fall directly under “IPFS” namespace.

IPLD:
IPFS nodes and gateways don’t support ../ipld/<cid> request directly & ENS isn’t supporting IPLD yet. Support IPLD Contenthash - #7 by 0xc0de4c0ffee … Technically “IPFS” namespace is IPLD with “fs”, IPFS gateways don’t have ../ipld/<cid> path as IPLD is too broad with long list of codecs, & dapps are free to implement their own IPLD schemas that can only be resolved by requesting ipfs gateway.tld ../api/v0/dag/get?arg=<cid>.

IPNS:
It can be libp2p/ed225519, or secp256k1 keys or old deprecated dnslink contenthash so underlying gateway’s ipns/<cid/dnslink> resolving process is same for all. *note: it’d be nice to re-use eth/secp256k1 keys for ipns but it isn’t widely used/supported so we’re using libp2p/ed25519 keygen with deterministic secp256k1 signature’s hash as seed. ipns address by 0xc0de4c0ffee · Pull Request #10 · paulmillr/ed25519-keygen · GitHub

Other dweb storage/contenthash have their own namespace so it should be auto handled by those gateways after contenthash is decoded. Arweave & Arweave NS format is one example… IPNS is still slow & patchy with republishing and scaling issue so we’re also looking into “fake” IPNS DHT by storing IPNS data in L2…

We’re using raw codec (generated on-chain) as alternative to data:uri type mentioned in this draft/“abandoned” ENSIP. IPFS gateways have to do guesswork as there’s no mime/content/type attached in CID. if raw data starts with < it’ll try to render that as html… dag-json is easy json format but we don’t get direct dag-cbor/link traversing support in dag-json only… so we’ve to use dag-json wrapped in dag-cbor… IPFS gateways auto support dag-cbor so its all good even without data:uri support.

• Here’s one example of raw/html ipfs cid from our tests…
  https://ipfs.io/ipfs/bafkqb3qchruhi3lmhy6gqzlbmq7dy5djorwgkptomfwwk43zomwwk5difzsgk5rtfzsxi2b4f52gs5dmmu7dy3lforqsa3tbnvst2itemvzwg4tjob2gs33oeiqgg33oorsw45b5ejwg63thebsgk43dojuxa5djn5xcepr4nvsxiyjanb2hi4bnmvyxk2lwhurhezlgojsxg2bcebrw63tumvxhipjcgm5vkusmhutwq5duobztulzpnzqw2zltpfzs2zlunaxgo2lunb2weltjn4tsepr4nvsxiyjaobzg64dfoj2hspjcn5ttu2lnmftwkiramnxw45dfnz2d2itior2ha4z2f4xw4ylnmvzxs4znmv2gqlthnf2gq5lcfzuw6l3mn5tw6ltqnztsepr4f5ugkylehy6ge33epe7dy2bshzjgkzdjojswg5djnztsa5dpea6gcidiojswmpjcnb2hi4dthixs63tbnvsxg6ltfvsxi2bom5uxi2dvmixgs3zchzxgc3lfon4xgllforuc4z3joruhkyronfxtyl3bhyxdyl3igi7dyl3cn5shspr4f5uhi3lmhy

@raffy

data: seems really interesting with L2 stuff.

@raffy

  uvarint(0xDD) 
+ uvarint(len(mime)) + mime utf8 bytes // eg. "text/html"
+ uvarint(len(payload)) + payload bytes 

And a separate protocol that sidesteps the URL-encoding.

Our core idea of using RFC-2397 datauris as hex in contenthash instead of multicodes is to simplify whole process… Just use hex(“data:…”) to encode and decode back. We don’t have to wait multicodecs support for everything. As we’ve mentioned before mime/contenttype in CID is loong pending for CID?v2, original issue is still open since 2016, last active PR is out there from 2022.