ENS Display Name: "FirstLast.eth" or "CAPSLOCK.ETH"

💬 General Discussion
#1

Imagine you want your ENS name to be formatted like FirstLast.eth or CAPSLOCK.ETH. This extra formatting lets your users know they’re interacting with the correct name and provides a visual checksum.

  • The normalization process casefolds so both of these names present like firstlast.eth or capslock.eth.
  • The reverse record (primary name) is per-account, not per-name.

Let’s claim a new coinType X, such that addr(node, X) now corresponds to the display name as UTF8.

Since this field can be set to anything, I suggest the following process for rendering the display name:

  1. input = "firStlasT.eth"
  2. normalize: norm = normalize(input) => "firstlast.eth"
  3. lookup: node = namehash(norm)
  4. display: addr(node, X) = "FirstLast" Edit: text record could also be used
  5. count the number of labels L in the display name L = countLabels("FirstLast") = 1
  6. check that normalize(first L labels of norm) == normalize(first L labels of display)
  7. if so, swap with the display: FirstLast.eth

Examples:

  • raffy.ETH w/display Raffy (L=1) → Raffy.eth
  • capslock.eth w/display CAPSLOCK.ETH (L=2) → CAPSLOCK.ETH

Note: the L optimization just makes it so less bytes are required in the common case. If you want to style the full name, you pay for those bytes. A more advanced solution could query the remaining labels for additional formatting, but that seems necessary.

If you don’t set a display, the normalized name is your display name.

Using this protocol, any name could be checked to see if it matches the display name (the well-intentioned case). This also encourages the use of capitalization to increase readability.

This is also a solution to FE0F being ignored and ZWJ being dropped from new emoji sequences, since the owner can choose any UTF8 sequence that normalizes to the same value.

Lastly, this can be implemented today w/o any changes: just pick X and provide a function ens_display(name: string): string that performs the process above.

8 Likes
ENS Name Normalization
#2

Regarding first and last name. It already does much better and what is good is that I use my domain name for my surname and subdomains for my daughters and me, so I have: ed.berrios.eth, laura.berrios.eth, and valerie.berrios.eth.

#3

It sounds like a good idea - vastly expanding the available computations for names to be registered - but is it, really?
If it were to be adopted, I envision it causing problems on a scale greater than the increased flexibilty that it appears to offer.
Not least, the absolute need to know, exactly, the capitalisations in the correct place. Human beings tend to like things being easy, to whit ENS, with its current system, has provided a solution to the long string of numbers previously required as identification. With the subdomain option present, a vast number of combinations are already possible.
Don’t get me wrong, I kind of like the idea. But knowing human beings will be involved, the possibility that a single uncapitalised letter will mean that funds sent are transferred to someone who will not give them back remains an ever-present threat that cannot be ignored.
It could become an extreme annoyance and very costly, to boot.

2 Likes
#4

For those that read this, I addressed part one and F3nt0n addressed part two of raffy’s points.

Name registered on etherscan but not on Ens
#5

No, this does not expand the available names at all. This simple means that if your name is, aaa.eth, that you can choose between [“AAA”, “AAa”, “AaA”, “Aaa”, “aAA”, “aAa”, “aaA”, “aaa”] for how you want your name to display. Notice, that all of those variants normalize to “aaa”.

The idea that I’m thinking about is that, when you enter an ENS name, if it’s exactly how the owner chooses, that’s an extra bit of information that you typed it correctly. Since most of the internet is Unicode, there should be no ambiguity when you copy/paste a name.

If you enter a name, but it requires a transformation to reach the normalized form, then you’re less confident that the name is correct.

The idea here is that instead of saying the normalized (lowercase) form is the “correct” name, it’s ANY form that also normalizes to the same name. Capitalization, etc. is just a visual checksum.

5 Likes
#6

This is a great idea but it’s orthogonal.

Set your display name to “Ed.Berrios”.

If “eD.berrios.eth” is typed into a ENS field, even though it normalizes to you, it still requires a transformation to reach the normalized form or the display form, meaning that the input is unnatural and should get extra attention.

If “Ed.Berrios.eth” is typed into an ENS field, it also isn’t the normalized the form, but it corresponds to the display form, so the input is correct without modification.

2 Likes
#7

Oh, my apologies. In that case, I rather like the idea!

1 Like
#8

Gotcha! Your first paragraph clears it up for me on the capitalization.

2 Likes
#9

That’s different than the combining of the first and last name into a domain name rather than the subdomain.domain.eth

#10

Doesn’t this overlap a lot with primary ENS / reverse records? We could get 90% of this just by specifying that the primary ENS name need not be normalised - but must normalise to a name that resolves to the same account.

1 Like
#11

Since you can only have 1 reverse per account, no.

The use-case I’m imagining is: what is the best sanity check when you enter an ENS name into an input field? — Answer: it is already normalized.

Unfortunately, many names require a transformation to become normalized, so they’ll never pass this test. And it’s hard to have a general rule that says what transformations are safe and what aren’t.

With a display name, the owner could say, “Raffy.eth” is the right form, then use that form everywhere, and then when people type it or copy/paste it, even though it requires a transformation, it just as valid. In this setup, I would say the normalized form “raffy.eth” is also equally valid. And every other form, that requires a transformation is suspect.

The default case (no display name set) is that only the normalized name is valid. ENS users with emoji names could set their display name to resolve the mismatch between what’s input and the normalized form. Then, encountering an unnormalized name becomes a useful bit of information rather than a silent error.

2 Likes
#12

For display, 99% of the time the app will be reverse-resolving from an address that it’s stored or retrieved.

For input, I think we need to treat all names that normalise to the same thing as identical. It shouldn’t be flagged as ‘suspicious’ if you have caps lock on or give your name an initial capital letter.

2 Likes
#13

I very much support this idea. I want my l.lawliet.eth to display as L.Lawliet.eth

3 Likes
#14

I agree with those points but I’m coming at this from the UX perspective.

If I’m sending crypto to an ENS name, IMO there’s a difference between:

  1. name is already normalized (or matches the display name)
  2. name when normalized is registered, but is not what was typed in
  3. name is not registered

I was thinking, why not show user feedback (like a checkmark) if the name is already normalized? And then I imagined typing in 6️⃣9️⃣.eth and realized this would fail.

The owner of 6️⃣9️⃣.eth surely isn’t sharing the name as 6⃣9⃣.eth, so I thought, why not have display name which can then be set to 6️⃣9️⃣.eth such that the checkmark should be shown.

No reverse happens in this situation. Nothing prevents the user from using the resolved address. This doesn’t solve or prevent homograph attacks. But it does put a large distance between the common case and questionable input. Additionally, it lets owners express their true name without mangling on a per-name basis.

2 Likes
#15

Another good use-case from today is the new .eth.xyz profile page. They have no way showing the canonical name. The only name they can show is the name you typed in via DNS or lookup name() for effectively the same thing.

1 Like
#16

I agree and would have that too
Especially in your case with 2 capital L it’s crystal clear the letters are L and not I… that would make it easier to transact safely too

1 Like
#17

I really think applications need to normalise names when they’re entered, so users see what’s actually being resolved. See for instance how browsers do this if you enter a domain name with capital letters and then hit enter.

ENS Name Normalization
#18

If I understand this correctly, this is the purpose for the display key in EIP-634, which allows a canonical representation for an ENS name during display (the namehash must match for the name and the value of the display field.

2 Likes
#19

Created: 2017-05-17

Oh, awesome. I was not aware of this EIP.

What do you think about the first L-label idea? Unnecessary complexity to save a few bytes?

When I was thinking about it, I was imagining that `ABC.CamelCase.eth" could set “ABC” and then defer to “camelcase.eth” for the remaining display, but that seemed too complex so I just left it as an argument to save bytes.

Your recommendation of using “display” as a TEXT record seems great.

#20

Solidity has a fairly sensible implementation of string and byte array storage - strings less than 32 bytes long only consume 1 storage slot. Longer strings consume one slot for the string length, plus one slot per 32 bytes. So in most cases there won’t be any difference between storing “foo.bar.eth” and “bar.eth”.

One issue with using a text record for this is any situation in which we might need to process it onchain. Dot-separated names are a lot more gas-intensive to process than DNS-style (length-octet-prefixed) names, which is why we’re using the DNS format in the new name wrapper contract.