ENS Normalization with {FE0F} inclusion - ENS Fee and more

@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.

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 - :joy: [1F602] has a single seq code so one needs to register 3 of them minimum. While for :face_in_clouds: 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:
image
is not the same as: Cat + Black

  1. image
  2. image


(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.