UTS-46 Non-compliant Emoji

Even without a Solidity version, this is incredibly helpful. And yes, making the ‘compressor’ part of the build process would be crucial!

Feel free to DM me so we can arrange some compensation for this valuable work.

1 Like

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?

I generally agree, and just so we’re all clear, there are a few cases this comes up:

  1. Copyright. There is the non-emoji “Latin” unicode character “©” 0x00A9 (simply the copyright code point). and the emoji character “©️” 0x00A9 0xFE0F. which reads “copyright, in emoji form”.
  2. Woman Superhero. “:woman_superhero:” 0x1F9B8 0x200D 0x2640 0xFE0F, which reads “superhero + (woman in emoji form)”. The woman symbol 0x2640 can be expressed in non-emoji form (♀), but as part of an emoji sequence, the “emoji” variation is required for proper display.

My only real concerns are:

  • If UTS-46 ever allows 0xFE0F, and ENS adopts the new standard, minimally qualified registrations would break.
  • Clients typically show normalized results to end-users. Displaying minimally qualified or unqualified emoji degrades the user experience.

Neither of these are deal-breakers per se, but I think ENS should be aware of them. If end-users aren’t meant to see normalized forms of ENS domains, clients should be discouraged from showing them.

Super cool! Upgrading from UTS-46 13.0 to 14.0 will definitely be a big help to support the newer emoji. To clarify some of the issues found:

  • England/Scotland/Wales flags are disallowed because they contain “tags”, disallowed in this part of the mapping section:
    E0020..E007F ; disallowed # 3.1 TAG SPACE..CANCEL TAG
    There are also “unofficial” US state flags which use these tags, so they’d also be disallowed. Not sure if ENS would ever want to include these as allowable in domains.
  • Japanese characters (and other miscellaneous characters) get mapped to different characters. Let’s take :u7533: 🈸 Squared CJK Unified Ideograph-7533 Emoji
    1F238 ; mapped ; 7533 # 6.0 SQUARED CJK UNIFIED IDEOGRAPH-7533
    On your app, this is normalizing to “盄”, which appears to be a chinese character, but I’m not 100% sure. Is this an accurate normalization for that character?
  • Ⓜ️Ⓜ️Ⓜ️.eth normalized to uuu.eth, which is odd. The circled M emoji is weird in that is has a lowercase form that isn’t an emoji, so it’s a bit of an edge case, but I wouldn’t expect it to normalize to “u”.

Really great tool though, thanks for building it!

1 Like

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

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

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

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

1 Like

:rainbow_flag:.eth is particularly finicky (even for emoji domains) and I can only resolve the dwebsite on metamask mobile browser (though I want to say Brave and Chrome used to successfully resolve the dwebsite, now they convert the emoji to punycode and it fails):

Metamask Mobile (iOS): “https://“ is required (https://🏳️‍🌈.eth) works. Https:// seems to be required of all my emoji domains on Metamask Mobile. Using .link or .limo (https://🏳️‍🌈.eth.link or https://🏳️‍🌈.eth.limo) will not resolve the dwebsite, but .limo and . Link work with my non-emoji ens domains. Using the punycode in any combination will not resolve the dwebsite.

Safari: No combination of https:// :rainbow_flag:.eth .limo/.link will resolve the dwebsite. Interestingly :rainbow_flag:.eth is converted to the Unicode “:white_flag::rainbow:.eth”. Also no combination using the punycode will resolve the dwebsite.

Brave (iOS): no combination will resolve the dwebsite. All combinations of :rainbow_flag:.eth perform a search but the punycode converts to the Unicode “:white_flag::rainbow:.eth” and attempts but fails to resolve the dwebsite.

Chrome (iOS/desktop): no combination resolves the dwebsite. :rainbow_flag:.eth is converted to the punycode and attempts to resolve the dwebsite and fails.

ENS manager: searching the ENS manager will show the content record and includes an IPFS hash link which of course resolves the dwebsite (but is painfully slow)

Have you entered your flag variants into my resolver demo?

These all resolve to the same thing.

1 Like

Just played around with your resolver demo…until then I thought I had an understanding of emojis.

You ser are the emoji :crown:.

Brilliant tool.