Codecs for ENS Contenthash: URI [0xF2] and Data URL [0xF3] #353
Conversation
|
I think this seems reasonable, though novel. I'm not so sure about introducing a new tag, Do you think you'll want more of these into the future? I wonder if we can't figure out a better tag whether this should just be an entirely new classification. @vmx, what do you think? |
|
I wonder if URI could use a Multiaddress instead. Would that be an option (I know to little about the Eth/ENS ecosystem). |
|
IMO, the closest codec is I picked I think |
Keeping it simple makes sense. |
|
IIUC this is related to https://discuss.ens.domains/t/draft-ensip-17-datauri-format-in-contenthash/18048/28 and ensdomains/docs#165. Apologies for the long text, I'm going to be OOO for a couple days and wanted to make sure to leave some context. cc @lidel who has been involved in the ENS work and interop here since long before me 😅. TLDR:
Some thoughts: URI
Probably not multiaddress itself, but harmonization with something like multipath multiformats/multiformats#55 would likely make this work and be pretty sensible. It would likely also let us use the FWIW libp2p has recently proposed going the other way as well (i.e. representing multiaddrs as URIs multiformats/multiaddr#171). I don't in principle have an objection to a URI based namespace, the two byte range is probably fine although URIs could probably tolerate even three due to the size of the data. Perhaps more of an ENS-related comment, but want to call out:
Data URLSeems fine, although maybe the three byte range (along with arweave, skynet, etc.) makes more sense here given these will likely be larger anyhow. A few comments / thoughts:
|
everything is IPLD 😄 🙏 everyone, I'm one of author of that data:uri ENSIP draft proposal, https://discuss.ens.domains/t/draft-ensip-17-datauri-format-in-contenthash/18048 using simple namespace hex("data:") format. We did our homework before sending draft over ENS forum to make an exception for hex("data:") prefix for reasons below.. a) mime/content type support in cidv1 is pending for loong time (?wen cidv2?) b) ENS already supports string(data:uri) format in avatar records, ENS is not ready for such changes with new ENSIP specs, all contenthash MUST follow namespace+CIDv1 format. our current working specs for on-chain raw IPFS+CIDv1 generator without content/mime types.. import { encode, decode } from "@ensdomains/content-hash";
import { CID } from 'multiformats/cid'
import { identity } from 'multiformats/hashes/identity'
//import * as cbor from '@ipld/dag-cbor'
import * as json from 'multiformats/codecs/json'
import * as raw from 'multiformats/codecs/raw'
const utf8 = new TextEncoder()
const json_data = {"hello":"world"}
const json_cid = CID.create(1, json.code, identity.digest(json.encode(json_data)))
const html_data = "<h1>Hello World</h1>";
const html_cid = CID.create(1, raw.code, identity.digest(utf8.encode(html_data)))
This all works ok using json/raw data.. only down side, there's no content/type in CIDv1 so we've to parse/guess magic bytes in raw data on client side OR request ipfs gateways to resolve that. we can even use dag-cbor to link multiple files/ipfs cids.. but on public ipfs gateways there's no index file and ipfs __redirect supported. we've to happily decode that on our "smart" clients for now. Back to @adraffy's
|
|
@aschmahmann and @0xc0de4c0ffee thanks for the feedback. As for codec numbers, I'd be happy with any assignment. Initially picked lower numbers since these two codecs seem useful beyond ENS. Yes, you could put both From the ENS + web content perspective:
You are correct about the base64 overhead concern, but there is also URL length limits (vs body) Coffee, I put your response on ENS forum |
ENS (Ethereum Name Service) encodes
contenthash()using multicodec. The purpose of acontenthash()is to describe the web contents for a corresponding ENS name.Currently, ENS supports IPFS, IPNS, Swarm, Arweave, Onion, etc.
Example using IPFS:
vitalik.ethhttps://vitalik.eth.limo/contenthash()=0xe30101701220484da2f7f497cac307e2026282263630b8dd4c448c3436470f5b850b432ba868ipfs://k2jmtxt5zh5vu5y8r7em2che3d4ghyftfr6h1yofdhibxai88k1wj5uw0xE3correspond to multicodecipfs, the following bytes are a CIDv0We would like to support the following (2) new codecs:
0xF2— URI0xf268747470733a2f2f656e732e646f6d61696e732f<codec><uri: utf8-string>https://ens.domains/0xF3— Data URL0xf309746578742f68746d6c3c68746d6c3e68656c6c6f3c2f68746d6c3e<codec><len(mime): uint8><mime: ascii-string><data: uint8[]>mime=text/html(9ch)data=<html>hello</html>(encoding depends on mime)