Name Wrapper update

[nick.eth]

I just wanted to give a quick update on the status of the Name Wrapper contract.

@Premm.eth contributed a change that allows for upgrading to a new version of the wrapper. It functions such that the DAO must approve the upgraded version, and then individual users must execute the upgrade; upgrades cannot be forced by either party.

I contributed a change to refactor how subdomain replacement is controlled; instead of a flag on parent domains that prevents overwriting any child domain, there is now a flag on each domain that specifies the parent cannot replace it. This allows people to issue ‘irrevocable’ subdomains without removing their ability to control all subdomains.

We’ve refactored some of the methods that handle subdomain creation/update/replacement, to assume that the subdomain will also be wrapped. This simplifies the API a lot.

Jeff and I have come up with a way to enable fuses to have expirations attached. With the current version of the wrapper, we had the issue that fuses are burned ‘permanently’ but can still be revoked when the second-level domain expires and is reregistered. Integrating expirations for fuses into the wrapper makes this model explicit, and solves several issues we had:

• Because each name’s fuses now have expiration dates attached, it’s now possible to check if a name is ‘safe’ against interference by parent domain owners by checking just that name’s fuses and expiration.
• As a result, we no longer need the complex logic for checking a name’s entire hierarchy, and it’s now practical and affordable to check a name’s mutability onchain.
• Users will now be able to ‘rent’ subdomains by revoking their control over them for a limited period.

The rules around fuses and expiries are as follows:

1. Every name has fuses and an expiry for those fuses.
2. If the expiry is in the past, the fuses are cleared (set to their most permissive state)
3. The expiry can only be increased, not decreased.
4. The expiry cannot be greater than the parent domain’s expiry.
5. The expiry on a .eth second level domain cannot be greater than the expiry of the domain itself in the registrar.
6. Only the owner of the parent domain can set an expiry.

We aim to have the new version of the wrapper available for review some time this week.

[garypalmerjr]

Nice–This is A Lot of positive development!

Thank you, @nick.eth, @Premm.eth, Jeff, & Teams.

[zadok7]

Great job everyone who is working on this! Really some giga-brain solutions here. Very proud of you all!

To be clear on one thing, the Name Wrapper updates only apply to .eth ENS names correct? These updates do not apply to DNS names imported into ENS right?

Hoping the ENS Youtube channel will go over these changes in some kind of workshop or slideshow with a dev explaining the thinking and possibilities. A part 2 to this one:

ENS Workshop 1: ENS as NFT v2 (aka Name Wrapper)

Though, I’m not sure of what timing is most beneficial. When the new version is review-able? Or, just a workshop after it’s released?

Anyhow, this is all really exciting. Great work everyone.

[thenftverse.eth]

Very Nice Progress!

[nick.eth]

@zadok7

To be clear on one thing, the Name Wrapper updates only apply to .eth ENS names correct? These updates do not apply to DNS names imported into ENS right?

DNS names can be wrapped using the wrapper. Second-level domains (Eg, google.com) will be non-transferable, and DNS domains at all levels won’t be able to use fuses.

[aox.eth]

Will wrapped names be under a new, separate collection on OpenSea?

[garypalmerjr]

@aox.eth, Yes.

[meta8.eth]

This is great news! You guys are incredible and the community holds you all in such a high regard. Have you seen / heard some of the things people are building out there ? Some really really “Enspirational” ideas being worked on.

[0-9.eth]

What is everyones take on the cb.id move by Coinbase? To me it seems offensive towards ENS in nature as it seems they intend to establish the “standard” web3 domain name service as their own cb.id VS the decentralized ENS.

[nick.eth]

.cb.id uses ens - both the new features we just released to support offchain resolution and DNS integration. We’re delighted they’re building on top of it!

[0-9.eth]

Cool. I guess I just dont understand it well enough. Good to know though. Thank you.

[serenae]

I’ve got a question about the expiry and renewals.

Let’s say I have a .eth 2LD that is registered for 1 year. And let’s say I just want people who register subdomains to be guaranteed to own them forever (or as long as the parent .eth name is not expired).

When a subdomain is registered and wrapped, as I understand it, the expiry on that subdomain can only be set up to a maximum of whatever the parent expiry is. There is no way to say “this subdomain should expire when the parent expires”, you have to set an explicit numeric value. And if you want fuses to be active, then you can’t set the expiry to 0, because that’s just the same as the subdomain already being “expired”, and getData will always return unset/cleared fuses in that case. So I have no choice but to set all registered subdomains to expire in 1 year as well, since that’s the maximum that it can go in this case.

So I wrap that name and have a subdomain registrar, and issue a bunch of subdomains.

Now let’s say I renew the .eth 2LD for another year, calling the renew method on the NameWrapper. If I’m understanding correctly, this only updates the expiry of the .eth 2LD node in the wrapper, and the expiries of any wrapped subdomains are unchanged. So now the .eth 2LD expires in 2 years, but all the subdomains still expire in 1 year.

If my goal is to just have all subdomains expire whenever the .eth 2LD expires, then do I also now need to call setChildFuses for every individual subdomain (of which there could be hundreds or thousands), whenever the parent expiry increases? Or is there something I’m missing?

[taytems]

@serenae
That is correct, if you thought you were going to run into a situation like this it would be best to extend your name before issuing subnames.

You could also approve your own contract to use setChildFuses and then let users change the expiry themselves.

[serenae]

Makes sense, it would probably be more scalable to just let the subdomain owners re-up their expiry by themselves. It would be an extra transaction for them, but not something that should come up very often.

And even if the subdomain “expires”, that doesn’t necessarily mean they’d lose the subdomain NFT or anything, at least not immediately. It just means that the parent owner could technically now replace/rewrap since the fuses are now cleared.

===========

Editing this reply because I’m not allowed to reply consecutively

FYI great update here:

Deployment of new contracts (inc NameWrapper) to Goerli

Following the July audit, I am very happy to announce that today we have deployed the new suite of ENS contracts to the Goerli test network. This is an important step for the ENS protocol to finally release the new suite of contracts to mainnet, which powers the next version of our app as well various community projects that are also in the works. The new contracts that have been deployed are: NameWrapper New .eth Registrar Controller New Reverse Registrar New Public Resolver Exponential Pric…

@jefflau.eth I can’t reply on that thread, not sure if that’s intentional or not! But I was playing around with it and was wondering about the metadata service. Is that not expected to be functional yet, or is there a separate Goerli deployment for it? Because it doesn’t look like the ens-metadata-service.appspot.com/name/0x{id} endpoint works currently.

Will the same metadata service be used for both the current NFT contract and the new NameWrapper contract? I ask because the route /name/0x{id} returned from the StaticMetadataService doesn’t have a contract address in it, and we know that the NFT token ID for .eth 2LDs will be different in the old vs. new contracts. So just wondering how all that will work!