ENSIP 13: Reserved ENS name

🧑‍💻 ENS Development Developer Help
1

Opening here for discussion to choose an ENS name we can dedicate to documentation purposes.

I didn’t want to mention it in the ENSIP proper, but the specific thing we are trying to avoid is using “example.eth” in our documentation because somebody actually controls that. In the web world, example.com is reserved. Many people have used “MyDomain.com” and “YourServer.com” for examples, which of course for SEO reasons resulted in somebody setting up a domain there for web hosting and they got an immediate unearned rankings boost.

Live file: docs-5/ens-improvement-proposals/ensip-13-reserved-ens-name.md at patch-1 · fulldecent/docs-5 · GitHub

ENSIP-13: Reserved ENS name

Author William Entriken <github.com@phor.net>
Status Draft
Submitted 2022-06-29

Abstract

This ENSIP defines a specific ENS name, ###INSERTNAMEHERE###.eth to be used for demonstration purposes…

Motivation

When writing documentation, it is helpful to refer to a concrete name of something to inspire thoughts about how that thing might work.

For example, with HTTPS websites hosted on legacy DNS we can refer specifically to https://example.com.

Further motivation is discussed in the comparable RFC 2606 and RFC 6761. One important reason is that propogating documentation for a specific name, when that name is controlled by an individual party, gives that party a strong motivation to make malicious use of that name.

This specification standardizes one ENS name we can use for similar purposes.

Specification

ENS Name

The name ###INSERTNAMEHERE###.eth shall be reserved for this purpose.

It is currently locked and nobody is able to make any use of this name. Therefore everybody is free to refer to this name.

Clients

A client website or other tool using ENS MAY warn or error before allowing interaction with ###INSERTNAMEHERE###.eth as this can be a known undesirible action.

Examples

A documentation page may say:

You can input your own ENS name such as ###INSERTNAMEHERE###.eth into the box.

Backwards Compatibility

Not applicable.

Security Considerations

None.

Copyright

Copyright and related rights waived via CC0.

2 Likes
2

I think by far the simplest approach—and also a nice homage—is to use nick.eth for documentation purposes.

There’s a long standing tradition of using either the founder’s or the author’s info in technical documentation :slight_smile:

I had a pretty funny conversation with another support mod a while back on if we should use UK or US English for documentation, and I said that we should err on the side of New Zealand.

3 Likes
3

Yes, the UK/US/NZ language choice, I’m down to give homage to nick.eth and NZ! This has come up with the Learn Docs. Since we had multiple editors. With the translations coming out, I suppose UK English, AU English, NZ English could be selections in the doc website.

Also to build documentation using Nick.eth, that’d be up to @nick.eth to decide. Also, maybe the ownership of the actual name would be better ‘owned’ by the DAO? Since the DAO is facilitating/creating content, may need permissions to update for the content record of said name.

I guess a sub could be issued permissionlessly with new Name Wrapper though if using Nick.eth. I do love the idea of a dedicated .eth name to stand up documentation on. The content could be decentralized too so in case a web2 server hosting the docs went down, the decentralized content would still be available. In the same thinking with how the ENS App is available at app.ens.eth.limo… In case web2/centralized servers go down ENS names can still be registered. Would also like this with documentation. It would be great if the content is reachable in the event the documentation hosting server has some failure.

1 Like
4

@fulldecent Great proposal.

@zadok7 I agree with decentralized content.

And if DAO is not able to acquire example.eth than I am able to transfer ensample.eth for free. Or someone will come up with better name.

2 Likes
5

I really appreciate the thought, but I’d rather use something less personal.

How about rilxxlir.eth? It was the first name ever registered, the registrant is now lost due to an opensea mishap, but my account is still the controller, and I’m happy to transfer it wherever.

2 Likes
6

:grinning: :grinning:It’s also a good idea

7

Thank you. When you say the registrant is lost, are we to understand that no other natural person has a legitimate claim of ownership to that name?

8

Released an updated draft:

Updates:

  • Using rilxxlir.eth
  • Filled in other missing text
  • Assumes that @nick.eth is the “moral” owner of that name and we want to use it
  • Other minor wording updates

If that assumption is correct, and we have consensus here then this ENSIP has no further outstanding work and I request that PR be merged.

I’m not sure of the formal process here, but I’m assuming after that is merged as DRAFT then I should make a second PR to change DRAFT to FINAL and there may be some time period where that is reviewed. (And then after that I go update documentation.)

1 Like
9

I support to choose this name, rilxxlir.eth

1 Like
10

I’m not sure what you mean by that. I’m saying that the registration is owned by an account that does not have a private key or contract, and that my account is the controller.

11

This is one downside of picking this name. People would always ask the origin story of the name and we end up explaining the frontend bug leading to the loss of the asset which isn’t a positive association.

12

What about using ensdao.eth or ens.eth?

13

Got it. I see the registrant is 0x000000000000000000000000000000000edd899b. We can assume that nobody knows a private key for that account because it has a patterns of many zeros. And an arbitrary patterned account is very hard to get (e.g. see blockhashes).

Your externally-owned account is the controller. 0x0904dac3347ea47d208f3fd67402d039a3b99859. This account has sent transactions to the blockchain. e.g. https://etherscan.io/address/0x0904dac3347ea47d208f3fd67402d039a3b99859. So this means you control the private key. It also means that it is very unlikely any smart contract will be deployed that account, because such would be a hash collision. And hash collisions are very unlikely, we have never seen one in SHA-256.

The name expires in 2030. So at that point, anybody could get it and “do evil things with it”. Ideally we would like that this can be protected against others using it for a longer period of time.

Source: ENS App

14

Anyone can renew it at any point (including right now) for 100/1000 years extra, not just the registrant, so that’s not an issue.

15

I’ve thought about this. However I see it in more of a positive light. It speaks to the fact that ENS names can’t be taken or forcefully transferred. Not even possible with the first ENS name! So the story can be in a positive light also.

Transparency with mistakes also speaks volumes. I feel like the code is pretty rock solid even though I’m not a dev, I surmise it’s been more widely reviewed since then, and heavily pen-tested. There’s a great bug bounty program also. And I’ve been impressed with the processes in terms of code audits for smart contract changes. Anyhow, I don’t think using the name rilxxlir.eth has to carry negative associations.

3 Likes
16

Understood.

Great, I’m happy to submit this for DRAFT status (please merge that PR).

And then I will apply for FINAL status.

After that I can work on documentation per this recommendation. And hopefully a petition can be made against some DAO/community organization to renew that registration for 1000 years.

17

what is rilxxlir?

1 Like
18
2 Likes