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
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.
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? 
Here’s the “stopwatch” emoji:
There are (3) acceptable forms of this emoji:
Since EIP-137, the standard has been that FE0F is 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
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.
@nick.eth you’re always against squatting, even while advocating for ens fairy, what have you done to ensure no one pre-registers unicode released emojis which are yet to be released on devices. Apparently a few newer ones have already been registered since November or so and these emojis would be released to he public in 2024.
You speak a lot against squatting for someone who has done nothing to avoid it and yourself picked nick.eth, a trademark of Nickelodeon. Quite hypocrite, are we?
While I’m sharing a solution to avoid it and punish those who do, you for some reason are against it, same with @raffy and @serenae I’ve been suggesting pregistering FE0F version of newer emojis, adopting it and releasing it when they’re available.
What solution have you yourself found against it?
check this address for eg -https://etherscan.io/address/0x67b52643aec5d25F62197539f6C1f39702132d51
My best guess would be that one if you is a holder of one such wallet. It’s sad that other don’t yet understand about sequences so there’s only a few of advocating against it.
My suggestions :
I don’t think accusing like this is a healthy way to progress. But I stand with the suggestions you made, domain squatting is a huge problem in DNS, 1000s of quality domains remain unused because of a selected few. Apart from the idea to re-implement {FE0F} in newer eligible emojis, I suggest you all also read this FuelNomen blog and how they’re planning to fight this problem.
And this by @vbuterin
I agree with the fact that ENS DAO has hardly done anything to address these issues, which are not new to ENS.
They removed my last post LMAO
They removed it previously I’m posting again, removing any inappropriate words :
They’re a bunch of centralized people, sitting on ENS fees and only benefitting the squatters (perhaps their own alts). They don’t have time to read these blogs. Instead of complaining one should just profit off their inefficiencies.
While there have been txns you can check to see tornado and mixers have been used to fund wallets vesting the tokens, perhaps by @nick.eth himself.
https://twitter.com/LilNonfungible/status/1634773397270929408
You’d be surprised how less is their bug bounty award compared to any other protocol with a tvl this big. WGs are paid more than any random security auditor with a legit bug! @vbuterin would be proud of what ENS has achieved, they swapped $15M ETH for their own WGs and tasks which you’d wonder what they are, while a security auditor would barely be paid 250k for even the most critical bug they find.
I’m dumb to have been offering solutions to them to curb squatting and fee related issues, I could have just profited off it, literally wasting my time in the forum.
You could raise an issue or proposal and realize it soon how centralized their voting is, the sheer amt of voting power delegates have, incl that of coinbase is just pretty dumb. If you oppose what they do or offer a legit solution, others who have been benefitting from this would take you down, ponzi.
Just observe how few non US folks are there in the whole DAO and also how every time they just select their friends as the stewards. They’re taking free money from your fee for literally doing nothing substantial. Look back at how they removed @brantlymillegan for a tweet from years back.
There’s enough uproar from the community about how the DAO functions and makes decisions, but it’s of no use, you can’t do anything about it. Bunch of centralised thugs @alisha.eth @nick.eth
When I pointed to @raffy in the chat how the same ens would be worth 64x bec of a rule they implemented 7 years ago, his point is that thinking about the cost/fee is not his job and when I answered nick of it here, he just changed the context
They’re attending eth events with the DAO money.
