Totally agree ENS names are different, BUT it shows that underscores were used and revoked in the past in DNS to to the same reason why I am talking about not issuing the underscore in ENS
It’s history repeating itself, but as ENS is decentralised it can’t be revoked like on DNS, if it’s allowed it’s here to stay
No it doesn’t. Underscores not being allowed in domain names doesn’t have anything to do with those articles, it had to do with very old considerations for ARPANET hostnames. You can read about it in my comment here:
As I have been saying, used in sub-domains only, but not in the main domain name
They have also been revoked as they are a confusable, which is what I have also been saying for ENS
So why follow the same path when it’s already happened in DNS and they changed it
It obviously doesn’t work…
I am really not interested in litigating this further, and it’s a massive distraction from the normalisation function as a whole.
Underscores are permitted in DNS and will be permitted in the new normalisation function. End of debate.
Underscore is for file path word separation only imo.
im just gonna bump this one post up and pretend I didn’t reply before reading @nick.eth 's recent post.
Thought the DAO decided and not one single person??
Why are you not addressing the concerns of the people you are meant to be serving instead of dictating to them?
Raffy has already said this about mapping it:
Why not introduce it to allow DNS integration, but map it to the hyphen
This gives the best of both worlds, which is what Raffy was proposing
Just now what you are proposing in my view is a rug pull on anyone who has registered an ENS name with a hyphen in it
Coca-Cola.eth included along with all the others
Glad to see “_” is likely going to happen.
As it should.
Hello @raffy! Is there a new version of the Resolver over at: ENS Resolver ?
Thank you.
Edit: found my answer in the repo. package, thanks!
I forsee the mistake of sending money to a hyphenated name when it’s meant to be underscored and vica versa, 100%.
can you see people confusing “i” / “l” ?
Because the above looks an order of magnitude more confusable than “_” / “-” to me.
Its even more obvious in context
alllna / allina
hello-world / hello_world
They are distinguishable by physical location on a mapped keyboard.
( i ) and ( l ) are seperate keystrokes.
( i ) or ( I ) is mapped the physical keycap ( i ) or ( I ) on most standard keyboard layouts
whereas the ( i ) keystroke will produce ( i ) or ( I ) and not ( l ) or ( L)
( l ) or ( L ) is mapped the physical keycap ( l ) or ( L ) on most standard keyboard layouts
whereas the ( l ) keystroke will produce ( l ) or ( L ) and not ( I ) or ( i )
( - ) and ( _ ) is mapped the physical keycap to the right of { [ 9 ][ ‘)’ ] } and to the left of { [ + ][=] }
which can produce both ( - ) and ( _ ), which is same keycap
I will be pushing an update very soon. The current repo is behind and contains lot of experimental stuff. The next update should 100% match ens-norm-ref-impl.js but be ~20KB.
Totally agree @accessor.eth
ENS is not case sensitive which means either uppercase and lower case letters can be used and it goes to the same place
If for some reason someone uses capitals next to the hyphen or underscore, then if someone kept their finger on the shift key too long, it may make a mistake and send it to some other random address
This is before you even get to people trying to do identity fraud
eg: G-StarRAW.eth
They are using capitals next to the hyphen
Guess what, keep your finger on the shift key and you get G_StarRAW.eth
This can work both ways
You may think I’m just trying to protect my bags, but it is not just that…
If you need to introduce the underscore to onboard web2 names then do it, just map it to the hyphen
There’s no reason _IMCOOL_.eth and -IMTHEBEST-.eth shouldn’t resolve.
We registered c++.eth tonight, but looks like it won’t work. There’s no reason anything other than a . shouldn’t be allowed.
As for transposition…If you send to unchecksummed names, that’s a really bad idea if it’s a hash or ENS. When adding send addresses you need to have the checksummed address and match it. Then you can add to the whitelist.
Short digit ENS domains reduce the risk, but people still sometimes dial the wrong phone numbers. It is important for all UI to show both the resolved address and the ENS name.
That’s a good point if you only focus on the typing mechanics (which is likely be the lesser important factor here over visual recognition)
You need to visually interact with the address prior ( to see what it looks like) and after (once you have typed it). And see what difficulties (if any) are present during these steps.
Pretty sure you can fat finger every key imaginable typing in your phone device since you are placing your finger over the screen and not pressing specific keys. Which is why visual interaction IS what ultimately matters most.
My point is, being able to visually determinate what you want to type and what you have already typed with the lesser degree of confusability seems primordial (in which case _ and - just do NOT confuse each other) V.S the same keypad being usable to type 2 different things (Remember you are pressing a secondary key (shift) and therefore executing an additional motion, which you should be doing for a reason (and noticing on the process, this is pretty much the equivalent of pressing another key of its own mechanically speaking). ENS is never using capital letters anyways, so you shouldn’t be typing them on the first place, but as long as you can take a quick peak afterwards, you will be discernibly identify how G-Star looks blatantly different from G_Star
In this specific case. It has to past a visual recognition test and that’s what matters most
Exactly. I’m not quite sure that i’ve ever had to use a shift key in a domain.
Maybe in situations when manually entering URL query parameters. That will change every persons keyboard mechanics while typing domains /URLs.
I’m also thinking about verbally translating an address to someone phonetically.
i.e:
s, l, o, w, UNDERSCORE, a, n, d, UNDERSCORE, t, o, o, UNDERSCORE, m, u, c, h DOT e, t, h
s, l, o, w, DASH, a, n, d, DASH, t, o, o, DASH, m, u, c, h DOT e, t, h
more syllables linguistically.
think about audible advertisements .
it would be kind of annoying to hear someone saying underscore over and over…
Just thinking outside the box.
I’ve never used one either, but visually G-StarRAW is marketing the .eth name with the capital letter in the name, people will copy this and put in the capitals
The other problem with people verbally translating a name is some don’t know the difference between a hyphen/dash and an underscore, I have heard plenty of people call an underscore a dash, it is a confusable
The risk/reward ratio of having separate names for hyphens and separate names for underscores is just not there
is it just me that gets internally frustrated when you seeing a_filepath_that_has_too_many_words_than there_should_be.
I also think this could influence people to flood the namespace with meme like iterations with foul language and inappropriate gestures.
It really seems that there is conflicting opinions throughout the community. Seems like this would be a good issue to resolve through an unweighted vote given the fact this is a public good issue and not one of dao-governance.
Same goes for seeing afilepaththathastoomanywordsthanthereshouldbe
_ & - have their place
Glad underscores will be normalized, it had to be done. The majority of the ENS community (90%+) appreciates this decision
