Substrate Name Service Pallet

[shawntabrizi]

• Initial design

• impl StaticLookup

• Tests

• Benchmarks/Weights

• Docs

• Audit

[xlc]

what's the reason to use usize? Shouldn't we want to avoid them because it is different between wasm and native?

[shawntabrizi]

I dont think usize here is an issue, and it is just less code to write when checking against the len of a name. In either case I removed this now since I think it is better to use a hash instead of the name directly.

[xlc]

The new bid should starts before a name expires so it is possible to have no-downtime experience. With the current design, there are not cap on bidding period so for hot names, it can take some time to reach to goal, and the name will be unavailable during this period.

Also I think the current owner should have better chance to keep the name. For any ownership change, there should be a significant notice period. Otherwise there will be phishing attempts or name hijacking. Imaging when your store rent contract ends and someone come pays 5x the rent and ask you get out immediately. It doesn't sounds fair and secure.

[shawntabrizi]

@xlc I have solved your main issue around downtime by splitting ownership and assignment.

Much like a traditional domain, you can own the domain name, and later assign it to an IP Address or change it to a different IP at some later time.

I have it so that there is one more step after you have won the name that you can then assign the name to an account. This also allows an owner to change the target easily, without introducing a transfer_ownership functionality, which I would like to avoid for secondary markets and name hoarding.

What this also means is that when a name expires, you will keep your assignment until a new owner is found, however long that takes. This gives the previous owner plenty of time and ability to win the next auction. Without affecting their current ownership.

That being said, I am not a fan of any special treatment of a previous owner to be able to keep the domain. This should be a free market, and treating previous owners special would basically give an advantage to people who are first in the system. If someone really wants to pay some absurd fee to screw you out of your name, then that is fair game.

[xlc]

Let's say a parachain operates a decentralized staking pool that can manages nominations for people. People can send DOT to the parachain's named address and will receive redeemable token on the parachain. The profit margin for this parachain can be slim so the parachain operator won't be able to offer much to renew the name.

A malicious person can easily out bid parachain operator, take the name, and take all the incoming funds. All the parachain operator can do is put warnings "DO NOT SEND" but likely some will failed to see the message, or forget to update some automation or saved contact.

Incentive wise this is unfair to honest people. I wouldn't use this because it doesn't offer much long term confidence to name owners and their users.

[shawntabrizi]

@xlc It is easy enough to add a function extend_expiration which allows a user to pay some fee to extend the expiration, but I don't immediately see this as the right solution.

To start, it is completely obvious to me that no one who is sane should use the friendly name as something hardcoded in a contract or automation. Anyone who would do this, could simply look up the underlying address at the time of creating some automation, and use that value instead. It is not justified to me at all that people should take dependencies on the fact that a name points to a certain place.

Allowing people to renew their domain forever is in strong support of name squatters. One of the solutions to squatting is exactly allowing new auctions to occur for a given name and allow the market to decide who should get it. If someone is willing to pay 5x more for bryan than you are, why should they not be entitled to it? I feel a name service would be useless if a few whales controlled all the good names, with no chance of losing ownership of those names.

As for any sensitive situations which I am missing, I have already introduced a manager origin and a permanence origin which can solve these issues. Let's assume a manager origin is council and permanence origin is the set of identity registrars or some democracy vote or something... Then you, as an important part of the ecosystem, still have the ability to reach out to these parties and make a case for them to give you permanent ownership of a name.

So really, I can not currently agree with your assessment here.

[shawntabrizi]

In any case though, although I think we disagree on philosophy, we def don't disagree on customization. I will add such a function behind some configuration.

[gnunicorn]

what's the progress here?

[antonkhvorov]

That would be cool to have I think

[gnunicorn]

closing for a lack of progress.

[ntn-x2]

Has nobody picked this PR anymore? We might be interested in developing a name service pallet, so I was wondering whether there's already something we could build on top of.

[shawntabrizi]

We are going to opt for something which much closer resembles ENS, so closing this for real real.