Unexpected STRINGPREP_CONTAINS_UNASSIGNED error

[NoahZinsmeister]

As reported in Uniswap/interface#2876, users with emojis in their ENS names are experiencing crashes due to a STRINGPREP_CONTAINS_UNASSIGNED error being thrown in #namehash. While this is solvable for us, perhaps it points to some underlying issue in ethers, hence the issue.

The following code errors, as tested here: https://github.com/Uniswap/interface/pull/2925/files#diff-5505dde3421656b51959add7972d69203d6faa0dfc3f05a7835c455799f2fac6R9.

import { namehash } from '@ethersproject/hash'

namehash('🤔')

[tlammens]

Encountered the issue as well, seems like ens has switched from ascii to unicode recently, see:
ensdomains/eth-ens-namehash@f62f351
from:

function normalize(name) {
  return name ? uts46.toAscii(name, {useStd3ASCII: true, transitional: false}) : name
}

to:

function normalize(name) {
  return name ? uts46.toUnicode(name, {useStd3ASCII: true, transitional: false}) : name
}

[ricmoo]

I’m having a meeting tomorrow with another Nameprep library author to discuss this too. I’ll update this issue afterwards. :)

[Arachnid]

Encountered the issue as well, seems like ens has switched from ascii to unicode recently, see: ensdomains/eth-ens-namehash@f62f351 from:

function normalize(name) {
  return name ? uts46.toAscii(name, {useStd3ASCII: true, transitional: false}) : name
}

to:

function normalize(name) {
  return name ? uts46.toUnicode(name, {useStd3ASCII: true, transitional: false}) : name
}

ENS has always used unicode, but the app was mistakenly using the wrong function to normalise names for a short while.

[ricmoo]

I think I may need to update the A.1 Table, so I’ll look into that asap.

[ricmoo]

As an update, this is something that is currently being worked on by the ENS team.

Ethers will not be making any changes to its nameprep library until the normalization for some certain edge cases have been worked out, but this is something they are actively working on.

[baptistegreve]

Hey! What is the recommended workaround for this?

[ymonye]

Ethers will not be making any changes to its nameprep library until the normalization for some certain edge cases have been worked out, but this is something they are actively working on.

Yup, same issue here

[lucashenning]

Same issue here. This is the root cause of the issue with avatars not resolving for ENS domains with unicode characters. ensdomains/ens-metadata-service#50

It works in @ensdomains/eth-ens-namehash

var namehash = require('@ensdomains/eth-ens-namehash');
var hash = namehash.hash('🚀🚀🚀.eth');
console.log(hash); // 0x8b50b6b0bfdea36f1149d2db0416f850c555439892d9464c722a51783fd8b2ae

[ricmoo]

Any updates, @Arachnid?

As I understand the prolem, please correct me if I’m wrong:

The @ensdomains/eth-ens-namehash allows names which are invalid according to nameprep, which the ENS spec specifies should be used during namehash.

The ethers library correctly restricts these names, which contain UTF-8 emoji joiners which are a zero-width character placed between emoji to indicate their relationship; i.e. should the emoji code points be merged into a single emoji (e.g. space + person = astronaut) or kept separate (e.g. space + person = space emoji then person emoji).

So there is an effort to expand the ENS namehash specification in a way that no longer has this restriction, but also impacts no existing names and is as future-proof as possible, as UTF continuously adds new characters and meanings to joined emoji.

So that is what this issue is about, getting that updated specification, again, as I understand? :)

[Arachnid]

I'm not sure which of Ethers and eth-ens-namehash is correct here, though I think it's eth-ens-namehash; ZWJs should be stripped rather than forbidden. Either way, we're working on an updated spec and implementation that is more permissive now.

[ricmoo]

Oh, if that’s the case I can make that change then. I’ll look up the zero width joiners and see if they are in the A.1 table.

[ricmoo]

I've been digging more into this. The problem doesn't seem to be zero-width joiners, as originally thought.

The Unicode character specified above is strictly prohibited in the A.1 Table, for example 🚀 is code-point 128640 (0x01f680), which falls in the range 1D800-1FFFD near the end of the A.1 Table.

So, I think to correctly support Unicode, we will need to expand the specification away from nameprep, or at least with an alternate A.1 Table.

[ricmoo]

If you want to follow along with the progress, here is the ENS discussions and progress updates:

https://discuss.ens.domains/t/ens-name-normalization/8652

[ricmoo]

The latest ENS name specification is now supported in v5.7.0.

Try it out and let us know what you think. :)