Add ENS Namehash

[0xc0de4c0ffee]

Adding ENS Namehash at 0x99 in table.csv

eth-ens-namehash, ipld, 0x99, Ethereum Name Service (Namehash)

base32 - cidv1 - dag-pb - eth-ens-namehash-256 - de9b09fd7c5f901e23a3f19fecc54828e9c848539801e86591bd9801b019f84f
ipns://foo.eth as namehash CID ipns://bafyjsaja32nqt7l4l6ib4i5d6gp6zrkifdu4qscttaa6qzmrxwmadmaz7bhq.

Ref : ethereum/EIPs/issues/137
ENS labels are normalized as UTS46 with the options transitional=false and useSTD3AsciiRules=true (https://www.npmjs.com/package/eth-ens-namehash)

[rvagg]

I don't think this should go with the ipld codecs for ethereum, if this goes in the table it probably needs to be elsewhere so we can keep the eth block formats together (as they will likely expand). This isn't a block format thing as far as I understand.

It seems to me that your example should be eth-ens-namehash + keccak-256 in base32, dag-pb shouldn't be involved here unless you're trying to achieve something else.

Excuse my ignorance on this one but can you explain the purpose of this codec? How would it be used? It seems like you might be able to treat it like an ipld codec, where the data is the eth name, but I'm not sure why you would do this. Is it just useful as an identifier? An address in applications distinct from the human-readable names (if so, why?)?

Having keccak-256 in the table and being able to produce a multihash for it would at least give you that information about what's being hashed. Adding a codec for it too would mean that you need a way to differentiate that this hash is of a very particular thing. An ipld codec suggests it's one that you could decode (and encode) into a usable blob of data. If that's not its use, there's still some scope for a codec to say what type of thing the hash is identifying, but it'd be nice to have a basic justification for that purpose. hash in the name suggests we need to have some clarity on the purpose I think.

[0xc0de4c0ffee]

Namehash is used as internal identifiers in ENS so as a "hashing algo" there's no easy way to reverse lookup foo.eth.

.. where the data is the eth name, but I'm not sure why you would do this. Is it just useful as an identifier?

Yes, that's the case in this full circle of ENS domain + IPFS/IPLD + content-hash. It's an identifier pointing reverse 0xde9b09fd7c5f901e23a3f19fecc54828e9c848539801e86591bd9801b019f84f >> foo.eth.

In this context data stored is normalized foo.eth itself and digest is node hash identifier used to query ENS resolver for ipfs://contenthash in foo.eth. I'm thinking this as CID bridge between machine and human readable names.

1. ENS.eth text without namehash as IPNS/ identity (unicode/hex)
2. Namehash as hashing algo/one way internal identifier only.
3. ENS namehash as IPNS identity with UTS46 normalized IPLD reverse lookup.

Nearest is (3), it'll be something like ENS graph protocol for reverse namehash lookup.
https://thegraph.com/explorer/subgraph/ensdomains/ens

1st auto use case will be as https://www.4byte.directory/ but for namehash stored outside of ETH mainnet.
It can also be used as bafyjsaja32nqt7l4l6ib4i5d6gp6zrkifdu4qscttaa6qzmrxwmadmaz7bhq.ipfs.dweb.link, a fixed IPNS redirect in browser/extension instead of temp redirecting foo.eth to latest **contenthash**.ipfs.dewb.link.

I'm using IPFS in my ETH codes for years but I'm still new to IPLD & CIDv1. I'm pro'lly missing something in this bigger context..

🙏

def namehash(name):
  if name == '':
    return '\0' * 32
  else:
    label, _, remainder = name.partition('.')
    return keccak256(namehash(remainder) + keccak256(label))

namehash('') = 0x0000000000000000000000000000000000000000000000000000000000000000
namehash('eth') = 0x93cdeb708b7545dc668eb9280176169d1c33cfd8ed6f04690a0bcc88a93fc4ae
namehash('foo.eth') = 0xde9b09fd7c5f901e23a3f19fecc54828e9c848539801e86591bd9801b019f84f
labelHash = keccak256("foo") = 0x41b1a0649752af1b28b3dc29a1556eee781e4a4c3a1f7f53f90fa834de098c4d

IPLD Put :
Store UST46 normalized "foo.eth"

Ipfs.dag.put("foo.eth", {
    format: 'dag-pb',
    hashAlg: 'eth-ens-namehash'
  }) 

IPLD Get
Returns "foo.eth" from IPLD

Ipfs.dag.get("bafyjsaja32nqt7l4l6ib4i5d6gp6zrkifdu4qscttaa6qzmrxwmadmaz7bhq").then...
>>
{
    domain: "foo.eth",
    // node: "0xde9b09fd7c5f901e23a3f19fecc54828e9c848539801e86591bd9801b019f84f",
    // root: "0x93cdeb708b7545dc668eb9280176169d1c33cfd8ed6f04690a0bcc88a93fc4ae",
    // label: "0x41b1a0649752af1b28b3dc29a1556eee781e4a4c3a1f7f53f90fa834de098c4d"
}

IPFS/IPNS Get
Resolves contenthash as "ipns://foo.eth" using namehash/nodehash digest

Ipfs.get("bafyjsaja32nqt7l4l6ib4i5d6gp6zrkifdu4qscttaa6qzmrxwmadmaz7bhq").then..
OR 
Ipfs.dns("bafyjsaja32nqt7l4l6ib4i5d6gp6zrkifdu4qscttaa6qzmrxwmadmaz7bhq").then..
>>
{
    contenthash: "ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco",
    // domain: "foo.eth",
    // node: "0xde9b09fd7c5f901e23a3f19fecc54828e9c848539801e86591bd9801b019f84f",
    // root: "0x93cdeb708b7545dc668eb9280176169d1c33cfd8ed6f04690a0bcc88a93fc4ae",
    // label: "0x41b1a0649752af1b28b3dc29a1556eee781e4a4c3a1f7f53f90fa834de098c4d",
    // owner:"........"
    // ttl: ...
}