Trying to understand the new official wrapper-contract code;
Seems like we may not have “sovereign renewals” for sub-domains,
…which would be sad, foreseeable, and a negative factor for the wrapper. TBD.
Yeah, the name wrapper is not a subdomain registrar. It will merely enable such registrars to be more easily created.
In your own subdomain registrar, you will be able to configure registration/renewal with whatever rules you want.
Just wait until users discover:
"any/all renewals" will be ruggable 
This sets the official ENS name-wrapper up for failure, imo.
I don’t know what you mean by that. Can you explain?
The fuse system will be able to ensure that the parent owner will not be able to delete/replace subdomain, until the expiry of the fuse.
What exactly is “ruggable” here
=====
Edit: Are you talking about how people can renew their own .eth 2LDs at any time? And you want to see that same thing for subdomains?
If so, that will still be possible I believe, but that logic would reside in the subdomain registrar, not this wrapper contract.
Your subdomain registrar can be setup with a renew function callable by the owner of the subdomain (or anyone, if you wish). The same way that the ETHRegistrarController has a renew function callable by the owner of a .eth name (or anyone else).
It’s up to the parent owner to decide whether they want to allow that or not.
It’s also worth reminding everyone that the NameWrapper is the first important step here, but it’s not everything. Subdomain registrars are separate, and I imagine there will be a variety of different such registrar contracts to choose from, each with their own parameters and levels of sovereignty, etc.
After release,
when someone uses the official ENS name wrapper,
and they sell/rent a subdomain (for one year), of their 2LD,
…even with “all of the right” fuses of the 2LD are burnt…
then:
Q: will it be possible for the “renew function”
(of the subdomain) to be removed by the 2LD owner?
The “sovereign subdomains” will exist,
…but “sovereign renewals” may-or-may not?
How will end users know if the “renewal option” can be hidden/removed or not?
That will depend entirely on the subdomain registrar contract(s) that you have setup for your own domain.
As an example, the ETHRegistrarController determines how registrations and renewals happen for .eth 2LDs. The ENS DAO can vote to change parameters for registrations/renewals, like the fee structure, etc.
Case in point, there’s a discussion here about changing the minimum registration duration (and possibly also the minimum renewal duration): https://discuss.ens.domains/t/a-suggestion-for-future-min-registration-duration-and-grace-period/12396/6
The same will apply to your own subdomain registrar/controller. You could set it up so that everything is completely locked and cannot be changed by anyone in the world. You could delegate that power to a multisig account with several trusted parties in the ENS domainer community. You could even create a whole DAO around it, if you wanted to.
While you are correct,
this is NOT what people are expecting.
- Expectations = Reality.
- Perception = 9/10th of Reality.
Congrats to us?
We are about to create a vacuum,
which is going to cause chaos & confusion.
Being this far into the process, & not caring about market expectations, is bad business development; and it is bad for users, too, (whom will be confused, frustrated, and will make decisions because they don’t have all the needed info.).
IMO, This is a dis-service for the official wrapper, and the community,
which will result in an increased rate of forking from the official contracts,
in addition to users being hurt by an absence of info from technical builders.
More information is needed BEFORE we are
this far into releasing a major process & infrastructure.
I see a lot of words there, but I’m having trouble understanding what your issue is.
What “disservice” are you talking about? The Name Wrapper is an excellent and much needed first step.
I know you want features A, B, C, D, E to all be here yesterday. Today A is shipping. B and the rest will come.
1 Like
lol, yes, I want the very subtle feature of,
“users not getting scammed by the official ENS wrapper contract”, via negative-unintended usage.
If this contract allows users to rent-subdomains,
and also allows the 2LD owner to remove the renewal-option,
then this is not a simple “feature” request–This is a Critical Alert.
The Core team has not shared any of this info with the community.
…We are just told that the wrapper is to be done soon 
-
There is no community discussion I see of the “subdomain registrar contract”,
which will be needed-and-required to setup for the users’ own domains, properly. -
There is zero communication that users will be buying ruggable rented-subdomains,
which will be ruggable (when renewable is not-possible) right out-of-the-box,
(…if those users are not identifying the right “subdomain registrar contract”).
Questions:
-
When will there be communication to the ENS-Community
that we need to start building “subdomain registrar contracts”? -
When will there be communication to the ENS-Community
[that they if they don’t use the right “subdomain registrar contracts”, then]
…it will be possible for the ENS Subdomains to be “taken away” from them,
(via the 2LD-owner possible “removing their ability to renew the subdomains”?
Nothing is “ruggable” here.
A customer purchases a subdomain for X amount of time. When the subdomain is registered and wrapped, that expiry (and appropriate fuses) is set. During that agreed-upon time between the customer and parent owner, that subdomain will not be able to be “rugged” whatsoever.
If the parent owner wishes to, they could also allow customers to extend that expiry date at any time.
Or, if you’d like people to be able to register a subdomain basically forever, I believe you’d just set the expiry to the maximum value, something like 580 billion years in the future. Edit: Actually that’s wrong I think, the expiry can’t be later than the 2LD expiry. So for “forever” you’d set the expiry to 0, I think?
It’s all up to the owner of the parent domain and what they want or don’t want to do with their name. There are a great many people in the ENS community, and I would wager that not all of them want to be bound to the same registration/renewal rules that you personally think are important.
There are plenty of use-cases besides reselling/speculation as well. For example, maybe you can use subdomains for your company employee roster or hired contractors. In cases like those, it probably makes sense to not burn all fuses, and leave some control with the owners of the actual company.
Nobody is stopping any 2LD owner from allowing renewals, or not allowing renewals. It’s their name, they have the freedom to set whatever rules they want.
======
With all that said, your questions are definitely good ones.
The core team is working on a canonical subdomain registrar:
That will (I’m guessing) be integrated into the new v3 manager app at some point as well.
However, I don’t know what features / rules that registrar will have. I would guess almost all of it would be able to be tweaked and dialed by the 2LD parent owner though. Perhaps you, @nick.eth, @jefflau.eth and others can get on a twitter space sometime and hash all of this out, ask questions, etc. I think it’d be a good idea for the core team to get feedback on what should go into that canonical subdomain registrar.
2 Likes
Being Technically Correct < User Expectations.
I hope being correct is enough, because this is not what the public wants.
Your technical understand is an anthesis of our communities expectations.
Actually, I am a bit shocked at the views.
When a users buys a subdomain, they will be expecting they will be able to renew it forever.
It is shocking to think, that the devs do not think, that this is a major issue for end-users.
Your solutions may be errors-in-thinking about the problems or solutions of end-users.
I’ve not seen collaboration, or cross-communication, or surveying of subdomain users.
This all reinforces that the perception that the devs are not understanding the market.
I predict this will be damaging for the official wrapper, and will accelerate division.
If dev-vs-user ideas live in different worlds, then evolution will diverge greatly.
I do wish the devs would had/will be inclusive of & would listen to actual users.
For the UX, the fact is that subdomain-rentals are ruggable if = not renewable.
Now, there is a lot of education that will be required; and even more to build.
Again, they will be able to renew it forever, if the parent domain owner sets it up that way.
1 Like
Right, the problem is not for subdomains that are transferred for “forever”.
The problem’s only for “subdomains renewals” that are “less than a lifetime”.
1 Like
No, it’s not a problem there either. Again, the parent domain owner will be able to set up their domain such that subdomains will be able to be renewed/extended by the customer (or anyone, if they want).
Will it 1. be possible for the 2LD-owner to:
“remove the ability (for the subdomain) to renew”?
…2. is this how the official wrapper contract will work?
1 Like
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:
- Not every 2LD has a DAO to govern the rules like the ENS Registrar has the ENS DAO. This is not a tech problem, but a governance problem. If somebody wanted to set up a multisig and transfer ownership of a 2LD to that for shared governance before selling subdomains, they could. I would argue they should.
- The .eth TLD is locked, whereas 2LD’s are impossible to “lock” because they have renewal fees. The workarounds are either to pay for 100+ years of renewals up front and burn fuses for the entire duration, or to handle this via governance as mentioned above (also probably in the subdomain registrar contract but I’m not as clear on options there).
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.
1 Like
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.
1 Like
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).
1 Like
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.
1 Like