Subject: ENS UI and consequences of faulty logic in ENS processes and smart contracts that disallows fair solutions that can be adaptive to multiple use cases
I am not able to open a temp check as i just registered but i will try to put here some details I find useful of processes or logic that needs to be fixed to my opinion
Due to a recent mistake in the UI of the ENS I revoked rights of mine over a newly registered domain that I bought at a temporary premium. I reported it and the UI got fixed overnight. Long story short the domain was wrapped. The UI was indicating the parent (eth) had permissions over my domain and I could go on and revoke. The wording was wrong, it was actually the owner who was losing the permissions. Now the domain is locked. It will only reset permission after expiry. But not during grace period. After grace period when owner loses his domain and it goes to public hunting.
- to start from the basics, i find it wrong to wrap newly registered domains by default. this advanced functionality should be enabled by experienced users if they needed the functionality of a wrapped domain NFT. not the reverse going from wrapped to unwrap.
- locking a domain should have a different logic. i understand the use cases that need a lock to be immutable. say subdomains are sold to be perpetually owned and they need guarantee the owner won’t resell the domain nor reset the subdomain so they need locked wrapped domain with burned fuses. all good. But see, mistakes like mine happen by accident or even worse by other’s mistake like a wrong UI of an app you use. The logic in the smart contract should be different, performing a few checks and allowing to unlock a locked domain, if those checks pass. Check if the domain has any subdomain with different ownership. If subdomains are all owned by the very same owner as the top domain there is no reason for locking as you take ownership rights from the unique single person that owns the domain and that’s by definition is unacceptable as the very essence of web3 is perpetual uncensored ownership. if someone wants to lose access they can send to burn address rather than being locked out.
- i will take it one step further. actually allow for unlocking even when all owners agree to. so check top domain and subdomains and let owners vote for unlocking. these would save situations where unlocking is critical to allow the domain to keep working for decades to come due to changes that we may not be able to think of today.
- i don’t know how fast and how possible it is to allow existing locked domains to get the above fixes, they are surely to consider for future wraps, but one fix for those unfairly or accidentally locked out already and need permissions reset, I would suggest the MINIMUM following fix:
- a. allow locked domain owners, with no other owners/managers involved at any level (top or subdomains), to restrict extension function of their domain by others. this would disallow others to extend the problematic domain perpetuating the situation and allowing ONLY the owner to extend keeping the extension under control.
- b. finally allow locked domain owners 10 days after grace period ends, to renew the domain they just lost access to without the domain going to public through temporary premium, but at least they have had the permissions reset so they regain access to fuses etc. This would apply to ALL locked domain owners even if they have subdomain owners that are different and so extension is allowed by anyone. The logic is that if nobody has interest to extend the locked domain then it is fair to ALWAYS propose it first to its owner in a reset state, before it goes to public hunting for a premium.
The above fixes I believe would make the ENS properties more reliable.
I don’t have ENS voting power, I wonder if anyone can help me with the above and I am open to hear suggestions about these ideas.
As a programmer myself these are changes I would have implemented beforehand but hopefully we can have a solution even now after the messy situation 
