Eth.cd - A social hub for ENS domains

🌱 ENS Ecosystem
14

I’ll have to refine this some more but this is technically (3) ideas.

  1. templated calldata (bytes[]) in addr(C)
  2. minting immutable calldata under *.profile.reverse where:
    • addr(${keccak256(calldata)}.profile.reverse, C) = calldata
  3. the multi() / version = 2 for better multicalls

Just focusing on (1), to query a profile, you’d fetch the following calldata:

  1. addr(latest.profile.ens.eth, C) = calldata for "current standard records"
  2. addr(your name, C) = (optional) calldata for "your extra records"

Union that together and then read those records.

This is essentially the shapes idea from MerkleResolver.sol and idea (2) is a shapes registrar that makes abcd...1234.profile.reverse.

This makes it so:

  1. the DAO can publish new standards
  2. the official app can use latest.profile.ens.eth
  3. clients can use whichever standard they have rendering support for
  4. users can supply their own records
  5. offchain servers can expose their custom records

To make it fancier, the user’s profile has a custom resolution process, which is: if the data you read from addr(C) is 32-bytes, intrepret it as a namehash and loop until you get 0 bytes or abi.encoded calldata.

This makes it so:

  1. name A can use their own template
  2. name A can use the template of another name B
    (use parent, use community, etc…)

eg. a.b.eth can have addr(a.eth, C) = namehash(b.eth) and addr(b.eth, C) = <calldata> specific to the b.eth community, which might include extra records like text("height"), addr(69), etc.

I think this is much better than literal key or coin arrays:

  • text("more keys") = "key1, key2, key3"
  • addr(<some number>) = abi.encode([1, 2, 3])