@nick.eth would love to know your thoughts on the above highlighted points
I defer to Raffy’s expertise here, and very much prefer anything that minimises the number of existing domains that are affected.
my suggestion doesn’t affect existing domains but rather reduces registration cost of newer 578 more emojis (and 100s of combinations). The idea sparked from one of Raffy’s comment itself. I don’t see a reason why we shouldn’t do it.
2 Likes
I don’t think changing how names are normalised for pricing reasons is appropriate. We should choose the best normalisation independently.
1 Like
regarding pricing, the change though is not small to think of it as inconsiderable. $640 for what could be $120 or $5, applicable to combinations as well.
More so, I have also talked about this, asked these questions -
Adopting EF0F versions for the newer ones don’t make new issues other than to label them seperately as Raffy has pointed previously.
Can you give an example of emoji names that would cost $640/year, that you think should cost $5/year?
2 examples from the new 548 ones
26F9 FE0F 200D 2B05 FE0F
stripping off FE0F makes them both 3 characters long instead of 5 characters. This makes their individual registration cost $640 instead of $5 each.
This is just one, there are 100 of examples where it should cost $5 but due to stripping it’d cost $160 or $640
These appear to the user as a single character. It seems totally reasonable to me that they should have a registration cost on par with a 3 character alphanumeric domain.
there are many that appear as a single character Nick, for example this one right here. This shouldn’t be the reason to treat a selected set differently. Moreover I believe I have raised a right issue here - what happens if EF0F becomes relevant 10 years down the line?
1FAF1 1F3FB 200D 1FAF2 1F3FF ; fully-qualified E14.0 handshake: light skin tone, dark skin tone
Shorter names are rarer and attract a higher registration fee. That’s the entire premise of tiered fees on ENS, and it seems to me that this fits just fine.
Then, in 10 years we will need to revise our normalisation function.
some emojis are made of single character code and some are made of 5 like I showed above, ‘shorter names’ doesn’t tell which ones you’re talking about. Ofc shorter names like fox.eth should cost more but in emojis’ context that changes due to the number of the codes in the sequence.
Infact one of the widely used emoji - 
[1F602] has a single seq code so one needs to register 3 of them minimum. While for 
this just one emoji is enough
Who are we to decide what is rare and what is not when that should be something that the buyers and sellers should decide in a marketplace.
Additional FE0F only makes them cheaper and don’t cause any issues for previously registered ones.
would the previously registered non FE0F versions be made invalid in that event? If I register all new 100s of emojis in their stripped FE0F versions (from ens.app) and in future it EF0F becomes relevant - would I be refunded for all if normalization causes issues?
in the cases like above the first emoji could have been independent but stripping FE0F didn’t allow that, would you terminate another set of emojis if FE0F becomes relevant in another future case?
Also since we’re talking about reducing the character count - ZWJ sequence {200D} is used as a joiner for multiple emojis - if I come up with a solution to not count that as a character just like {FE0F} (Variation selector), would the DAO also strip that off in character count and thus normalization?
It would reduce many 6 character ones to 2-3 characters. If you propose we reduce character count as much as we can to make them rarer and expensive then I can put my efforts to devise some ideas. Doesn’t seem impossible to me.
cc - @raffy
Black Cat:
is not the same as: Cat + Black
(unfortunately I’m on legacy Windows atm)
ZWJ/200D is essential structure, FE0F is not.
FE0F is not essential in our current knowledge and we don’t know whether some browsers or even unicode picks it up for a new variation. Also the cost factor, 64x price inc makes no sense when the other one can be adopted.
1 Like
I’ve read through this post and it’s quite a debate. Even I register domains from the contract directly and had 2 such emojis neglected in the past but I still register my emojis and digits from the contract without depending on any frontend, I’ve my own custom solution.
I think kraft’s point is not completely void. If the cost can be reduced substantially with such an upgrade, it should be given a consideration. I also agree with his future application of fe0f in new browsers/apps.
At the same time, I understand @raffy’s point that he’d have to rework it. If kraft suggests he could help, then maybe raffy and him could work together. But 200D can definitely not be removed @kraft, if you’ll notice many emojis have multiple too and the emojis cannot be rightly rendered without it.
I only support FE0F inclusion.
imo having a Unicode representative in conversations related to emojis could be very helpful.
My suggestion to remove 200D was because they considered removing FE0F in the first place. While I agree 200D is imp, FE0F could be instrumental in the future - not to mention, why choose their outdated versions, strip off a sequence element and then inc the price multiple fold.
@nick.eth asked me an example of one and I confidently gave him multiple such examples above.
I’m happy to assist if needed, after all the idea emerged from one of raffy’s previous comments only.
You’re proposing that these poops are different names? 
Let me clarify this one more time:
-
Here’s the “stopwatch” emoji:
-
There are (3) acceptable forms of this emoji:
-
Since EIP-137, the standard has been that
FE0Fis ignored.
FYI: there are more than 100k names with emoji. -
Therefore, they all get normalized to the same thing:
-
You can use ANY of these forms for lookup or display however there is only ONE normalized form.
Technically, the specific choice is irrelevant — for example, the “stopwatch” emoji could have normalized to the string 8asx798a67sd — the only critical fact is that this canonicalization remains constant for the life of ENS. It has nothing to do with Unicode or correctness or outdatedness or renewal price. This decision was made years ago and thousands of ENS users depend on this fact.
Emoji handling is just a fancy variant of case-folding: similar to how RAFFY.ETH, rAfFy.eTH, and raffy.eth are equivalent, the same is true for emoji like “stopwatch”.
No Raffy, I am not suggesting they’re different, but definitely their sequence code is different right? Anyway I think my support was more in favor of the change if it lowers the cost drastically. Also when I check unicode’s recent doc linked by kraft above I only see the FE0F version marked as fully-qualified.
Doesn’t that mean that even more emojis with no FE0F might increase the cost exponentially at the user-end? The 3-4 char combinations are less but still it does make a difference 
We can continue to retain previous emojis and still be able to make the changes for new ones maybe?
Note: I respect your contribution, only supporting kraft here because the cost factor does seem valid to me
1 Like
Exactly what I’ve been trying to point, if something has been happening for a while that doesn’t mean it can’t be improved further. Furthermore FE0F is a variation selector and I speculate it might be of use in future browsers/apps probably few years down the line. Adopting primitive versions doesn’t set right logically. It only confuses the registerer further like in this case, I’m not the only one - Registered Emoji contains "EF%B8%8F" symbols
Right now we just assume it’s useless, while I’ve also shown examples above how FE0F makes a huge diff in price and in the appearance of a few emojis, and could be of importance in the future.
in your own words @raffy
Continuing the discussion from ENS Name Normalization:
I’m with the opinion that the DAO should consult Unicode or alteast be a part of the consortium.