currently domains expire in ~100 days. At any time one can re-acquire for next 100 days.
I am proposing in the PR, to switch to annual rent. Also at any time one can re-acquire for full next term (so in practice, have almost 2 years of ownership). I feel it gives a lot of stability and good UX. If a domain is not re-aquired it is back in public pool.
BTW. this was original question, why I created this topic. What’s your preference?
BRI
I don’t have big opinion here, as having BRI is part of the larger picture of governing this funds.
Just pouring tokens into the bucket will not reduce the risk of software project failure.
Ownership
I see how the system you proposing is more fair in some cases. I am afraid of its size and complexity.
Especially, about the dependencies in multiple layers of the organization. This is why, personally, I am fan of protocol level solutions.
Token appreciation
For the case when ae token jumps from $0.50 to say $5000, it would indeed throw whole economy of minimal fees off balance. If that happens, tho, we can either propose a solution (e.g. a proxy that computes co-efficient for minimal prices) OR this will be finally the moment to remove whole minimal fees mechanism as platform is popular enough to make free market mechanism useful.
It is not our intention to make people pay a lot of money for a domain. We look for fair pemissionless moderation mechanism of domain rental.
I have a feeling that you actually would be more comfortable with permissioned design of this feature. Like selling rights to managing name trees to an organization/company that will handle all clients requests.
I prefer the annual rent and like the possibility to extend the ownership for the next term. there should be an API to query the time to expiration.
to make this even more user friendly you could think about certain checkpoint dates (01.01. - 31.12) where the term starts and ends. then people would always know when their domain might expire. but claiming a name in november must then be way cheaper then claiming a name in february. don’t know whether this adds too much complexity. but I think it is more convenient for everybody.
you could add the option to directly claim for the next term when registering the domain:
just a few thoughts about that.
I was noticed that the .test name would be kept onchain for ever, ~21K .test names were registered from aeknow.org.
How shall we deal with these .test names?
I was not aware of this promise of persistence.
If we delete them, they will fail to resolve.
We intended to purge test namespace, to lighten database. Also there was no bidding mechanism, so single party was able to acquire large amount of names.
What you think about it? Do you need those names? Or you had them for testing purposes?
@LiuYang.chain can you say what’s your position on potential .test namespace drop? (there would be no .test any more, just .aet. Names over 32 - up for discussion - would be available without auction)
Also, there is new proposal regarding proprietary names, following: If you auction proprietary name, you need to deal with it with legal owner. I kind of like it, as it suits permissionless blockchain philosophy.
I am an æpps person… I am slightly lost in the doc in the PR. Where exactly is the auction flow described from a user’s perspective? @michalzee
I will gather my thoughts on renting/renewal and post them later.
I would like to start thinking about the auction flow from the user side (and provide relevant feedback) asap.
Thanks!
hey @stoyan.chain
here is the doc: Name auctions by sennui · Pull Request #379 · aeternity/protocol · GitHub
EDIT: deleted note about second price
thanks! i will read before our call tomorrow.
How is this assuring that there won’t be any name squatting again? (directly claiming for the next)
And further more - its fairly easy to run a cron task to request the update for a domain name for you when its time.
@michalzee - This also apply for the proposed flow of getting the name for XXXX amount of AE and then XX for maintaining it. Isn’t this a problem if I can maintain the name with a script for lets say 100 years from now for 1000$ - how is this fair for others that want that name?
I tend to take @Kryztoval side here. We need to think of a better way of doing this than making another .com bubble. And also again as @Kryztoval said lets not forget that this naming system will be supported within aeternity network only, so it doesn’t make sense to charge more than an actual domain name.
I don’t understand the question, sorry
sure it is easy to request it. but I wasn’t only thinking about managing my own names. I would know for every domain when it would potentially expire.
I understand name squatting as a process of obtaining large amount of names, for the only purpose of holding it to re-sell for later proper business usage.
If this is just one name, re-newed, re-rented, every year, it seems legit use of it.
@bruteforce.chain from your post:
Expensive purchase & Cheap rent. Well, what can we do here? Both expensive?
Please follow up with some proposal and justification how it is more fair.
What’s another mechanism to avoid .com bubble?
There is argument that it makes sense to put “rent” on every on-chain entity. Names are even more expensive for full node as it has to track expiration.
I don’t have here strong opinion. Auction mechanism is very simple and fair mechanism - this is why we brought it up in recent Berlin meeting. As I understand, with Lima fork, the last one “official” fork, Aeternity wants to complete it’s product mission that was presented at the very beginning. It covered Naming System with auctions. It is hard to tell, how many silent users are just fine with it. Real game changer would be bringing here economy research about fair distribution of such desired and limited goods as Names. That said, it would be unrealistic to implement it for Lima = ERC20 expiration.