UTS-46 Non-compliant Emoji

[nick.eth]

@royalfork

My browser converted this to https://xn--og8hvo.eth.link/ , which doesn’t resolve. Maybe this is an eth.link/cloudflare issue? Is this supposed to work or are you speaking hypothetically?

Cloudflare should puny-decode before resolving with ENS. I’ll talk to them about this.

@royalfork

• If UTS-46 ever allows 0xFE0F, and ENS adopts the new standard, minimally qualified registrations would break.

We will definitely need to carefully evaluate new versions of the standard before rolling them out.

[raffy]

@royalfork

https://xn--og8hvo.eth.link/

I see the following:

• 🏳️‍🌈.eth == 1f3f3 fe0f 200d 1f308 2e 65 74 68
• xn--og8hvo.eth == 78 6e 2d 2d 6f 67 38 68 76 6f 2e 65 74 68 == 🏳🌈.eth

@royalfork

1F238 ; mapped ; 7533
Ⓜ️Ⓜ️Ⓜ️.eth mapping to uuu

This is the IDNA step, but then there’s NFC, but this was an off-by-one bug in my decompression code. Thanks!

Ⓜ️Ⓜ️Ⓜ️.eth now goes to mmm.eth
1f238 now correctly maps to 7533

[raffy]

Have you entered your flag variants into my resolver demo?

• [0x1f3f3][0x1f308].eth (separate emoji, upgraded)
• [0x1f3f3][0x200d][0x1f308].eth (only zwj, upgraded)
• [0x1f3f3][0xfe0f][0x1f308].eth (only fe0f, upgraded)
• [0x1f3f3][0xfe0f][0x200d][0x1f308].eth (full, but zwj is removed to match existing namehash)

These all resolve to the same thing.

[raffy]

Due to how many conflicts this causes with previously registered names, this behavior has been changed in my library and emoji are no longer upgraded. Essentially, ZWJ is optional, which results in multiple names for many emoji.

I think the example Nick shows me was:

1. 😵💫😵💫😵💫.eth → 0x372973309f827B5c3864115cE121c96ef9cB1658
2. 😵💫😵💫😵💫.eth → 0x0033AAdE458d0b39Ce0B1Ba2581859F2D5855555

These render identically for me on Windows+Firefox but look separate on my Mac:

Additionally, if these two examples represent AAA and BBB, then also AAB, ABA, ABB, BAA, BAB, BBA are valid, eg. 😵‍💫😵‍💫😵‍💫.eth