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:
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.
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.
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.
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.
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.
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.
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.
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.
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:
name is already normalized (or matches the display name)
name when normalized is registered, but is not what was typed in
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.
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.
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
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.
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.
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.
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.