Approval for ENSIP-15 should be confirmed through a social vote.
ENSIP-15 Motivation
Since ENSIP-1 (originally EIP-137) was finalized in 2016, Unicode has evolved from version 8.0.0 to 15.0.0 and incorporated many new characters, including complex emoji sequences.
ENSIP-1 does not state the version of Unicode.
ENSIP-1 implies but does not state an explicit flavor of IDNA processing.
UTS-46 is insufficient to normalize emoji sequences. Correct emoji processing is only possible with UTS-51.
Validation tests are needed to ensure implementation compliance.
The success of ENS has encouraged spoofing via the following techniques:
Insertion of zero-width characters.
Using names which normalize differently between algorithms.
Using names which appear differently between applications and devices.
Substitution of confusable (look-alike) characters.
This looks great to me. Technically the new app is already using this too!
Does a new ENSIP need a Snapshot vote? I see other newer ENSIPs too, but I don’t think we’ve ever voted on them explicitly, as they don’t affect the core ENS protocol.
In general no. Given this is a significant change in how ENS names resolve, which affects existing names, I don’t think there’s any harm in getting formal DAO approval for it.
Just checking, we’re all good to go with this right? Is anyone opposed to putting this up to vote on Snapshot?
I ask because I think OpenSea is waiting for “official” approval before they will do a full reindex (so that previously delisted names can be relisted)
Also it looks like Metamask is using eth-ens-namehash, does that need to be updated too? And then Metamask would need to update to that newer version?
However, there were a few issues with ens-normalize.js deployment related to npm and Typescript that should probably be incorporated into this fork for maximum compatibility.
Additionally, eth-ens-namehash was commonjs and the new build is esm. To reduce any upgrade friction, it should probably have a commonjs build.
Now that ENSIP 15 is submitted as a draft, this can proceed! @raffy, can you create a new EP instructions here and submit it as a draft? We’ll get it up for a vote on Snapshot.
Names visible to the end-user should be beautified for a more consistent appearance.
What do you think about adding something like the following related idea to the specification:
If the primary name of an account is not normalized then it should be treated as if the account has no primary name set.
There’s probably a better way to communicate that idea. It’s quite late here right now as I write this. The bigger goal behind this suggestion is to correct for cases where we see people set their primary name as a non-normalized name.
For example: Let’s say a dapp shows “ABC.eth” as a non-normalized primary name for account 0x123 to users in their UIs. Then someone copy-pastes that non-normalized name into a properly implemented text field that performs ens-normalize. The result is that the dapp actually interacts with “abc.eth” which might resolve to a different account 0x789 than the account the user thought they would be interacting with.
In practice, this would mean that the various libraries that implement the primary name reverse lookup logic would need to also perform an ens-normalize check, in addition to the other checks performed such as verifying forward resolution, etc…
Yeah, I agree with this, I was just unsure if it should be part of normalization or part of an additional document that covers best practices.
I included beautification as part of the spec because it requires normalization logic to apply it, but it’s really an UX thing that happens after normalization. For example, I have an demo page which demonstrates some of the issues (unpredictable emoji presentation between devices: compare mobile vs desktop, and some normalized emoji acquire text-coloring whereas beautified emoji do not: eg. make a text-style heart emoji appear blue vs blue heart emoji.)
I explored the invalid-primary case in my resolver demo: bld.eth. I also provide hints regarding address/owner/controller/primary sameness/mismatches.
There is another issue when a primary is set to an address-like hex string. This matters when a wallet is shown as one entity (ENS name or address) rather than both values. Across my various ENS experiments, I try to differentiate these two situations:
Since Normalization isn’t enforced on-chain, there is no code for the DAO to execute. Instead, approval for ENSIP-15 should be confirmed through social vote.
Although not critical to Normalization, I recommend that names visible to the user should be beautified for a more consistent appearance across devices. High-priority use-cases: ENS Metadata Service and etherscan.io primary names.
For example, these are the same emojis:
This is my first post in here. I’m not sure on the procedure or format.
We could ask: What would be the best way to support the case that libraries implementing primary name reverse lookups update their logic to be more safe with this proposed ens-normalize check?
Whatever helps to protect the community from potentially nasty unexpected edge cases seems best.
My suggestion would be to take this opportunity to include this idea in ENSIP 15 as I believe it’s an important detail in achieving consistent UX for the community in relation to normalized names.
Feedback always welcome of course
The case of someone setting their primary name to an address-like hex string is quite interesting My first impression is that while it is a bit odd, it should all pass the test of: If a user copy/pastes this name into a properly implemented dapp that uses ens-normalize, will they ultimately resolve that properly? And it seems to me that they should.
For the issue of clearly differentiating subdomains, I’m not sure I understand this one? abc.def.eth seems clearly differentiated from abcdef.eth for me.
All the ideas you suggested adding to technical docs sounds great
Edited above to be more explicit in communicating a suggestion.
I’d like to push a few minor formatting updates to my ENSIP-15 docs. I’d also like to include the minor addendum to ENSIP-1 which points to ENSIP-15. Can I just PR these changes to the docs repo?
I did not include Lightwalker’s suggestions as I think they should go in a different location. What’s the proper protocol for adding these suggestions? Figure out what edits to make with a thread and then PR the changes, or is something more formal required?
) this 
My first impression is that while it is a bit odd, it should all pass the test of: If a user copy/pastes this name into a properly implemented dapp that uses ens-normalize, will they ultimately resolve that properly? And it seems to me that they should.
