Again, it’s not part of nor the responsibility of the name wrapper contract. What you’re describing is up to the subdomain registrar.
Please read this again: ENS Subdomains, Pricing Methods (Rental Pricing Options) - #11 by serenae
The 2LD owner will be able to set everything up in a “locked” situation where nobody, not even the 2LD owner, will be able to “remove the ability to renew”. That is, of course, if the 2LD owner wants to do that.
The way I see it is quite similar to regular .eth names.
The ENS Registrar Controller is controlled by the ENS DAO, which means that the ENS DAO can vote to change registration/renewal pricing at any time. Once a name is registered for a set period, though, it cannot be affected until that registration period ends. Does this mean ENS names are ruggable? I think most people would say no, because of the governance model (DAOs are cool!).
Same situation with the name wrapper and subdomains. Fuses can be burnt for a subdomain by a 2LD owner for as long as they want (up until the 2LD expiration time), making the subdomain completely unruggable until that fuse expires. But the parent can change the registration/renewal rules after the fuse expires. It’s really the same concept as the ENS Registrar Controller IMO.
The only two differences I see are:
It can’t possibly be as easy as pressing a button that says “allow people to buy subdomains under my .eth name”. That being said, I do feel like the community has that expectation which is not ideal.
Yes, 100%; This is absolutely Ruggable.
This is a known “Attack Vector” for ENS.
This is an attack vector,
which we should all be aware is an attack vector.
Interesting. I’m personally more in the camp of practical/sufficient decentralization vs making large sacrifices in favor of absolute decentralization, but I guess that’s a longer topic for another day.
Either way, I hope I was able to illustrate why I feel that the name wrapper sets the framework for selling subdomains in a similar way to how the .eth root sells 2LDs (which has worked quite well up to this point if you ask me).
I totally see where everyone is coming from. However, I’m also concerned by the points that @garypalmerjr raises regarding users/market expectations.
The way I see it the implementation that’s currently in the works is good for organisations, companies, etc. where no extra guarantees are expected by end users. Something like a corporate email, where the company has full control over the email accounts and that’s it: they set their own policies, they can delete or create accounts at will, and so on.
@garypalmerjr is mostly talking about retail, where instead of me registering a 2LD, I decide to register a 3LD from someone else. There are many reasons for this. For example, cost, way of payment (in other tokens), the idea of belonging to a club, commercial incentives or even because someone is kind enough to give me one for free (to promote their brand, to promote crypto, whatever).
In this case, we can not expect users to check when the 2LD expires, learn about grace periods, etc, and know that the 3LD they just register may be invalid (or even worst, taken over by a new owner) tomorrow or in 17 days. We have to provide a design that will make users feel safe to use 3LDs as long as they pay for them.
The Name Wrapper makes it easier to make “unruggable” namespaces, but the definition of that is up to each subdomain space provider.
I think this makes complete sense, because “unruggable” has a different definition for different kinds of subdomains.
For example, a subdomain space where names are ownable only by the owners of an NFT collection. These need to be revokable, but a responsible subdomain creator could encode these rules into smart contract logic, so it’s not “ruggable” in the definition of what the namespace is, even though you can lose your name, which is against the top-level domain’s rules (where it can only happen based in a time expiry).
If you tried to make a universally “unruggable” subdomain space, you would make ENS subdomains not very useful, whereas the approach with fuses makes it possible to build UIs for users to understand what real guarantees they can expect and audit those guarantees, while still allowing a whole universe of possibilities on top of ENS.