Greetings. I’m not sure if this is the right place to post bugs in the ENS documentation; if not, please redirect me.
Name Processing - ENS Documentation says “…prohibiting names containing forbidden characters such as underscores.” By my count, there are more than 30,000 names in ENS that have underscores in their names. I suspect that this section needs to be re-written to indicate that the rules are advisory, not mandatory, and that names that break the rules can definitely be registered.
This is because these names were registered before the normalization standard was implemented. Many people seemed to take the chance on the decision that was then in limbo; that the normalization would include certain characters.
There are a few threads here regarding the topic. They are quite lengthy. But they offer comprehensive discussion about implemented standards as well as resources to tools.
I’m not sure that underscores are covered by the normalization rules. That is, many names like _primus.eth and _richardteng.eth were registered just recently
That character is allowed, but only at the start of a label.
That Name Processing page in the docs is old, before ENSIP-15 was approved, so that reference to “forbidden characters such as underscores” needs to be updated.
I’d suggest looking ens-normalize.js | ENSIP-15 in JS & normalization test page… There’s tons of invalid domains reg’d in ENS that’ll never pass normalization or resolve in browser… still we could even use “invalid” sub-domains to internally store text and metadata for our dapps.
The onchain .eth Registrar Controllers that control issuance of direct subnames of .eth “allow” any characters. This includes underscores, “.”, invisible characters, etc… These smart contracts only validate a minimum length for direct subnames of .eth. Given ENS has decided to accept emojis and other special characters as valid there are reasons (technical, economic, etc…) why enforcing ENSIP-15 at the smart contract level doesn’t make sense.
ENS is more than “.eth” or direct subnames of “.eth”. Other name issuers exist other than the onchain .eth Registrar Controllers. These can all “allow” whatever policy they want for issuing names. For example, there are over 4 million cb.id names that are all ENS names. Or check out all the subnames of dcl.eth from Decentraland. Or check out https://www.my.box/
However, properly implemented ENS clients should all be following the ENSIP-15 ENS Normalize standard. A properly implemented ENS client does not “allow” names that fail to meet those standards.
Distilling this down:
Name Issuance: Doesn’t require enforcement of ENSIP-15.
Forward Name Resolution: A properly implemented client always enforces ENSIP-15.
Reverse Name Resolution: A properly implemented client always enforces ENSIP-15. If the primary name doesn’t pass ENS Normalize it should be as if the account has no primary name defined at all.
This means there can be ENS names that technically exist but are unreachable by a properly implemented ENS client.
That’s unfortunate complexity, but if developers building on ENS are educated on these careful details it is all manageable.
There’s several gotchas here that could be good to put more attention on in ENS developer docs. For example: ENS Normalize should be performed on all names read from the blockchain (directly or indirectly). This includes smart contract events, the ENS Subgraph, ENS primary names, etc… Depending on the features being built on ENS, a dev can build their apps improperly if they only perform ENS Normalize on the text input fields in their app.
dang bro just learned more in that paragraph then I have in the years in web 3! thanks now what you know about this error I’ve gotten for the last year lol
