ENS Name Normalization 2nd

What about Norse / Rune languages and characters ? The scripting is beautiful and while not being very “human readable” - the letters and words do look appealing and would look pretty nice on etherscan !

For example:

ᚠᚢᚦᚨᚱᚲᚷ.eth ?

Runic is allowed, however since it’s an excluded script, the label must be pure (and can only mix with emoji.)

image


2 Likes

Wow that link you provided on excluded scripts get pretty deep pretty fast ! Yikes :sweat_smile:

But essentially I can still go an mint Runic or other special characters and set the reverse records if desired ?

Along with cool shapes like this:

⏣⏣⏣⏣⏣⏣.eth

I love finding and minting these unusual ones that are so different but look so appealing on or when SIWE on various apps!

Sometimes I think having domains that aren’t so much “Human Readable, but “Human noticeable” is such a hugely overlooked area by most.

I particularly love signing in to one of my Opensea accounts using an emoji domain that I set the reverse record on a while back from this wallet -

0x21b8defe3b23e6d701f407fa94dc64fe206041b3

:white_check_mark::sweat_smile::green_heart:

Keep up the good work man!

1 Like

The following 2 ports are now 100% match (across 2.7m labels) with the JS implementation.

I submit a PR for a few minor updates to the ENSIP-15.

4 Likes

Not a spec change, but I’ve made a small update to my Resolver:

  • Names that were Emoji + ASCII used to appear as Latin (because ASCII is specifically 7-bit). However, I now separate these cases and show an overall summary for the name:
    image

  • Names that are Latin but contain any of ąçęşìíîïǐł are now marked as “Potentially Confusing”. ENSIP-15 reduced the “modified ASCII space” from effectively infinite to a handful of characters, but there are still few marks that may go unnoticed:
    image
    image

This PR is still waiting for approval, although maybe it can wait for the pending Unicode update.


Unicode 15.1 will be released on September 12 (~2 weeks). I’ve built the library against the latest proposal files and ran it on all existing registrations:

  • :white_check_mark: There are 0 names that were valid that became invalid due to Unicode changes.
  • :white_check_mark: There are 234 names with Unicode 15.1 emoji that are now valid.

Changewise:

  • There are 118 new emoji, of which 108 are the new directional sequences, which flip the emoji.
  • No new scripts or CM.
  • 600+ new CJK ideographs.
  • There is (1) IDNA change that was never registered. It was actually disallowed in ENSIP-15 since I thought it should have been mapped, but now it is:
    image

Can we get the ENS Metadata Service to use the beautified result in the SVG and JSON?
Example: 9️⃣9️⃣.eth Resolver | Metadata
The <svg> rendering is the most important but "description" (and "name"?) can be changed as well IMO.
Note: modern mobile devices already force beautify system-wide.


I’ve been told Metamask is still having normalization issues. I was about to submit a PR to add ENSIP-15 support but encountered an issue with an older version of ethers. I talked to Ricmoo and the intention is to release a patch for ethers v5 with the latest ENSIP-15 support.


I recently upgraded my registration tracker which shows the most recent 1000 names under various perspectives:

2 Likes

Approved. In future if you add me as a reviewer I’ll be sure to see it sooner.

Thanks for approving the docs PR and deploying beautification in the metadata service.


I updated the ENSIP-15 spec files for Unicode 15.1.0. For implementers, there are no code changes required, just rebuild with the latest spec files.

As mentioned above, none of the Unicode changes impact any valid registered names.

New Emoji in 15.1


I’m currently looking for some clarity regarding URL parsing, as a few projects have moved to Ada’s URL parser, which follows WhatWG, which suggested CheckJoiners true, which disallows ZWJ, which makes punycoded ZWJ emoji names invalid, and thus unreachable over DNS. Clearly there’s some confusion here as the major browser vendors don’t even agree on some punycode rules. This is an implementation issue not a Unicode issue, similar to how it’s perfectly valid to use IDNA with useSTD3 false to allow underscore according to UTS-46.

3 Likes

ens-normalize-python by NameHash is also updated with Unicode 15.1.0 and pass new tests.

1 Like