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.
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.
Oh, my apologies. In that case, I rather like the idea!
Gotcha! Your first paragraph clears it up for me on the capitalization.
Thatâs different than the combining of the first and last name into a domain name rather than the subdomain.domain.eth
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 very much support this idea. I want my l.lawliet.eth to display as L.Lawliet.eth
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.
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.
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.
Yeah, I would recommend against unnecessary complexity, especially since as Nick pointed out, things are already fairly optimized in string storage, so more complex things may actually consume more space in some common cases.
Hereâs a really simple demo of the display name idea.
I set my âdisplayâ TEXT record for âadraffy.ethâ to âADRaffy.ethâ. If you enter your ENS name as normalized or matching your display name which is also normalized, then it shows as green.