Implement upgradeable LabelValidator that initially restricts names to same standard as Handshake/DNS
#3
Assignees
Comments
aoxborrow
changed the title
LabelValidator that initially restricts names to same standard as Handshake/DNS
|
Can I have a decent sample of passing and failing names so I can create unit tests? |
|
I assigned this to me as I would like to bite off something smallish. I'll do tests as well. |
Merged
aoxborrow
added a commit
that referenced
this issue
Aug 29, 2022
LabelValidator that restricts to ASCII alphanumeric, prevents punycode - see #3 forge install: solidity-stringutils, although not using currently update readme
aoxborrow
added a commit
that referenced
this issue
Aug 30, 2022
LabelValidator that restricts to ASCII alphanumeric, prevents punycode - see #3 update readme
aoxborrow
added a commit
that referenced
this issue
Aug 30, 2022
LabelValidator that restricts to ASCII alphanumeric, prevents punycode - see #3 update readme
aoxborrow
added a commit
that referenced
this issue
Aug 30, 2022
LabelValidator that restricts to ASCII alphanumeric, prevents punycode - see #3 update readme
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Maybe
LabelValidatorcould reference external contract so that we can upgrade to change Unicode or Punycode functionality in the future. We are basically punting on the decision to support full Unicode, because we need to be compatible with existing EPP rails.To start, we'll restrict to the same standard as Handshake and DNS (alphanumeric + hyphen), except that we'll also disallow Punycode (xn--*) and underscores. This restrictive set makes the names compatible with existing EPP registrar infrastructure, but also keeps compatibility with standard ENS/EIP137 resolving (Unicode), which is what current Handshake resolvers use (Beacon, Fingertip, HNSD). There are advantages to staying compatible with ENS such as using existing client libraries and simpler integrations. We should add validation to prevent Punycode names as the ENS standard is to use normalized and hashed Unicode. If we allow Punycode, duplicate names could be registered that both represent the same Unicode.
References
https://github.com/handshake-org/hsd/blob/master/lib/covenants/rules.js#L183
https://github.com/imperviousinc/fingertip/blob/main/internal/resolvers/ethereum.go#L98
https://github.com/adraffy/ensip-norm/blob/main/draft.md
https://discuss.ens.domains/t/on-chain-ens-domain-normalization/13202
https://discuss.ens.domains/t/ens-name-normalization/8652
https://discuss.ens.domains/t/dns-collisions-of-ens-names-in-browser-input/12539
https://discuss.ens.domains/t/suggestion-remove-punycode-from-ens-name-normalization/8025
https://github.com/ensdomains/punycode/blob/development/contracts/Punycode.sol
ethers-io/ethers.js#42
https://github.com/ethers-io/ethers.js/blob/608864fc3f00390e1260048a157af00378a98e41/packages/strings/src.ts/idna.ts#L7680
The text was updated successfully, but these errors were encountered: