err, sorry for bit late reply, I thought I already posted this, but it was still in draft.. so addin bit more context/origin story.
Sorry for mixup, under ENS context that’s dynamic contenthash.
eg, vitalik.jsonapi.eth
resolves to > https://ipfs.io/ipfs/bagaaiaf2af5se33lei5hi4tvmuwce5djnvsseorcge3tkmzxg4ztsnbxeiwceytmn5rwwir2eizdgmbsgmzdsmjcfqrgk4tdei5dalbcovzwk4rchj5seylemrzgk43tei5cemdymq4giqjwijddenrzgy2gcrrziq3wkrlehfstam2fguztimjviqztoykbhe3danbveiwce3tbnvsseorcozuxiylmnfvs4zlunarcyitcmfwgc3tdmurduirufy3tqmbwgu4celbcobzgsy3fei5cemzygm3c4mjxgm2dgobcpv6q
This ENS contenthash CIDv1 is “auto” update after each block/timestamp & vitalik.eth’s ETH balance/ price feed.
{
"ok": true,
"time": "1753773947",
"block": "23023291",
"erc": 0,
"user": {
"address": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
"name": "vitalik.eth",
"balance": "4.780658",
"price": "3836.173438"
}
}
As I’ve prev mentioned,
our tools support both multihash (sha256/keccak256) and raw/identity. 0x00 identity codec is used for onchain cid generation but underlying onchain data/payload isn’t static so that CID isn’t pinned anywhere offchain.
I’ve thought about extra bandwidth too, as we don’t have that data pinned offchain it’s not going to work without inlined data.. As backup plan we could use local Helia client or minimalist inline CID reader for this case. Another plan we’re looking into is to use TEXT records in ENS to return raw/inlined data for special pinning services, and then return multihashed version for contenthash.
bit recap,
all this started with our need for onchain contenthash generators, so we went back to adding plain datauri stringTohex("data:") = 0x646174613a prefix support in ENS contenthash but ENS devs want strict multicodec/multihash format.. Adding that simple non-colliding prefix support on top of ENSIP-07 contenthash specs would solve this issue (but limited to single file per contenthash).. Bit crazy, ENS is already using plaintext datauris in avatar’s text records.. 