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:
Every name has fuses and an expiry for those fuses.
If the expiry is in the past, the fuses are cleared (set to their most permissive state)
The expiry can only be increased, not decreased.
The expiry cannot be greater than the parent domainās expiry.
The expiry on a .eth second level domain cannot be greater than the expiry of the domain itself in the registrar.
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.
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:
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.
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.
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.
.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!
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?
@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.
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:
@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!
Pardon me for being slow, however what happens if you donāt wrap l? Seems like wrapping only really matters if you want subs? Ok Iāll go back into my hole now
Yāall have a good day!!
