PSP for Name Service on Polkadot

[shawntabrizi]

We need to create a community standard for Name Service on Polkadot.

Some existing work:

• https://github.com/pnsproject
• Name Service Pallet mark II paritytech/substrate#11052
• Substrate Name Service Pallet paritytech/substrate#7197

Primary Goals:

• allow DOT holders to register *.dot names which can be used to quickly look up their Polkadot Address
• have a single source of truth for these names, which helps prevent attack vectors and keeps users safe
• simple, easy, and cheap registrations for end users
• a smart way to backfill domains for existing users, trying to ensure that active or well known polkadot users (or even system accounts) get priority to register domains

[shawntabrizi]

For back-filling domains for existing users:

• Order users with public on chain information:

  1. System Accounts (treasury.dot, society.dot, etc...)
  2. Council Members
  3. Users with verified Identities, registering domains which match their verified identity
  4. Users by on chain activity
  5. Users by account balance

• Users submit a remark of the names they want, and we collect them using an offchain tool

• We disable the pallet to start, and use governance to backfill accounts

• Then enable the pallet to the public

[burdges]

It'll provide all the DNS record stuff, like MX, etc? We'd only run this on one parathread or parachain, but which one?

[shawntabrizi]

It is my opinion that for a first iteration of a name service, we should simply focus on a single domain: .dot, and have this live on the relay chain for simplicity and clarity.

Parachain slots are already in short supply, I don't think that this kind of application drives enough traffic which warrants its own slot. In the future, this could change of course.

[xlc]

.dot is a registered TLD. I don't think we can just use it without asking https://www.iana.org/domains/root/db/dot.html

[shawntabrizi]

I don't believe the goal here will be to register a web domain, or conflict with the existing .dot TLD.

The goal here would be to support address look ups from UI like Polkadot JS, Extensions, Subscan, etc...

In this context, .dot will just be used to specify a certain network within the Polkadot ecosystem.

[xlc]

But it will conflict and confusing. Anyone looking at address.dot will think it is a DNS entry (which it is).

[burdges]

.polka

[shawntabrizi]

@xlc Is there no such case that any blockchain nameservice has used a conflicting TLD?

[burdges]

It's a dangerous UX footgun:

Dish DBS Corporation owns .dot, not sure for what they'll use it, but name.com thinks they'll sell names eventually.

You might own shawntabrizi.dot on polkadot, but if I buy it from Dish DBS then anyone accessing it from a system without the right software sees my version, including from alternative browsers, like Tor Browser or another browser tunneled over SOCKS or a VPN.

The safest approach would be to buy .polka from ICANN.

[burdges]

In the short term, we could register subdomains ala *.polkadot.??? for some TLD ???

[lamafab]

Well, we already own polkadot.io, which redirects to polkadot.network. Could be used for that.

[ggwpez]

You might own shawntabrizi.dot on polkadot, but if I buy it from Dish DBS then anyone accessing it from a system without the right software sees my version, including from alternative browsers, like Tor Browser or another browser tunneled over SOCKS or a VPN.

I dont understand. Why would you enter this into a browser?
Its only valid within the Polkadot ecosystem, not the general internet.

[burdges]

If you say name service then people shall assume you mean DNS, and the conversation above does not disabuse this. If you want something else then it should be distinctive dot:* or whatever.

[shawntabrizi]

I am not against: dot:shawntabrizi. This looks better to me than any of the options above.

The goal of a name service, in the context of Polkadot, is to disambiguate accounts, and potentially other more opaque types (like a specific data object on the blockchain). I think we should really only focus on and worry about name resolution on Polkadot itself. How other parts of the internet handle certain string formats seems outside of the scope of what we can control.

[burdges]

There are various URI schemes but likely URNs make more sense here. An example is magnet:, which they designed after Freenet:, ed2k:, etc, and urn:dot:* maybe available even. But what does it mean?

[shawntabrizi]

But what does it mean?

In the context of what we want to achieve a standard for here, dot:shawntabrizi would be a lookup to the address 12hAtDZJGt4of3m2GqZcUCVAjZPALfvPwvtUTFZPQUbdX1Ud, which is my public address.

If i wanted to send you 5 DOT, I would type into my Polkadot wallet dot:burdges.

This PSP would be about standardizing what is stored on chain, how name registration happens, how long it lasts, how to renew names, etc...

https://eips.ethereum.org/EIPS/eip-137

This is something that the community is building unofficially, and unofficial version of this kind of feature can lead to issues, especially if there are "multiple sources of truth" and people start attacking the system to trick people to send DOT to the wrong place.

I would hope we can create a standard here, along with our community, build and launch something onto Polkadot.

[ntn-x2]

We think it’s a good idea to not use TLD here but go with URIs or URNs. We actually did the same with our w3n:john_doe names.

Another question would be about the scope of validity of those names. Would dot:john_doe be referring to the same entity as a potential kilt:john_doe? If not, this would open the system up for potential fishing attacks.

On a general level, it is really time to start considering potential fragmentation issues, especially when it comes to something as sensitive as "sending money to someone else by looking up their name". There are other solutions which are already live, for instance our Web3 Names solution and the pns.link project.

[jeluard]

.eth is not an official TLD and doesn't resolve in regular browser. It does resolve in 'web3' ones though (e.g. status). In this case it leverages eventual metadata associated to it.

The alternative URL scheme sounds interesting though. Would be nice to dig how it can be interpreted by browser natively via e.g. custom protocol handler.
Ethereum community investigated this already: URL format for web3 browsers, EIP-831. It might even be consolidated somehow with Parity's URI work on Universal offline signature?

[jeluard]

It might also be worth considering how this mechanism could be extended later on to reference things like assets on statemine.

[burdges]

It kinda depends upon (a) how else you want this to be used, ala email, etc., and (b) if you want to add payment stuff to DNS.

Can .eth addresses resolve to IP addresses, receive email, etc.? If so, can we use the same DNS extensions that make them useful for payments like Shawn asks?

I think .polka sounds unlikely to be hijacked by someone else. We could begin the application process so that nobody else can claim it, but then not go through with the full process.

Also..

Do we have any strategy to prevent name squatting even if we use dot:*?

[jeluard]

Can .eth addresses resolve to IP addresses, receive email, etc.? If so, can we use the same DNS extensions that make them useful for payments like Shawn asks?

DNS providers can offer ENS aliasing to some extent, e.g. .xyz supports it oob. Not clear how useful it is.

key/value pairs can be associated to ENS (like IPFS hashes). Then it's up to conventions and end user tooling to deal with those. This is what so called ethereum web3 browsers do.

[ntn-x2]

It might also be worth considering how this mechanism could be extended later on to reference things like assets on statemine.

Funnily enough, this is the next thing we at KILT are actually working on. We plan to define a new DID method (people against DIDs will most likely not like this) that can be used to refer to generic asset classes (and instances thereof) on any blockchain using a combination of CAIPs, or Chain-Agnostic Improvement Proposals.

These assets would be able to receive KILT credentials issued by KILT attesters, and because DIDs expose additional information via their service endpoints (which can contain messaging information, or even simply additional KILT credentials made public by their owner), the resulting information graph is much richer.

We think this is a more powerful and content-rich solution than simply working on a name <-> account aliasing solution, and we invite the community, especially that part of it interested in giving identity to assets, to get in touch with us for potential discussions and collaborations.

[HeisenbergLin22]

Thanks @semuelle for mentioning the Faceless project in this thread. The payment scheme of the existing blockchain networks such as Polkadot is based on blockchain addresses, usually random strings that are hard to memorize and manage. Therefore, it might lead to many inconveniences, such as funds being transferred to the wrong address. In contrast, traditional payment is usually based on human-readable identifiers (HRI) instead of random strings, which is a good reason. There are many application scenarios that require the payment to be based on one's HRIs. When you pay your debts to your friends, you want the transaction record to be bound to your identity so that it can serve as proof later that your debt has been paid. Or if you take a business trip, you want your accommodation receipt to associate with your company's identifier so that you can reimburse the cost later. If you go to a grocery store to buy some daily goods, you want the transaction record to have your own identity on it to prove to the grocery cashier you have paid the bill. As a matter of fact, you can find countless examples that demonstrate that it is preferable to have your payment based on HRIs instead of random addresses. Cryptocurrency has already brought fundamental change to the existing financial system and internet economy. The emerging Web 3.0 is starting to give the user back the ownership and control of their data. However, we believe to base the payment on HRIs instead of random blockchain addresses remains a final mile to deliver before cryptocurrency and Web 3.0 truly become mainstream and finally take over our daily life.

We have seen novel solutions emerging from various blockchain ecosystems that try to base payment on HRIs. The Polkadot name system (PNS) is a good example. However, most of these naming services focus specifically on providing HRIs for the users of one single blockchain ecosystem and fail to bridge the users of the different ecosystems and hence are against the "breaking the digital barriers" ethos of Web 3.0. Most importantly, the new HRI system fails to incorporate many existing Web 2.0 human-readable identifiers that users are more comfortable using in practice, such as their various social media identities, and email addresses (based on which PayPal systems are built), etc. We believe it is far more interesting to build a cross-platform payment scheme based on a generic HRI system that combines the users' existing Web 2.0 and Web 3.0 identifiers.

Unlike the current internet economy that is segmented by the digital wall garden erected by various internet monopoly companies, a cross-platform payment scheme will open up many interesting application scenarios that truly embody the spirit of Web 3.0. For instance, a Twitter user who doesn't necessarily have a medium account, when he/she sees a medium article he/she likes, he/she can simply tip the article author from his/her Twitter account via our Faceless protocol. If a Facebook user watches an advertisement on an estate NFT from Decentraland, he/she can pay for the NFT directly from his/her Facebook account via Faceless. A cross-platform payment scheme based on a generic HRI system will not only serve the purpose of bringing Web 2.0 users into the Web 3.0 world but also taps into this immense market and helps realize the full potential of Web 3.0.

Another limit of existing HRI-based payment solutions is the lack of privacy. This is actually closely tied to another interesting application of Faceless protocol, i.e., regulatory-compliant payment. Due to the explosive growth of Web 3.0 payment and its application such as decentralized finance (DeFi), NFT, etc, traditional financial institution is starting to migrate to Web 3.0. However, in order for the Cryptocurrency market to attract institutional money on a large scale, one has to address its regulatory concerns. The privacy issue is likely to play a central part in the regulatory compliance requirements. This has been demonstrated when Meta (previously Facebook) tried to launch its own cryptocurrency Diem (previously Libra). The most widely raised regulatory compliance issue of Diem during the senate hearing is the privacy issue \cite{Libra_privacy1,Libra_privacy2}. Faceless will provide a private payment scheme based on HRI and hence resolve the privacy issue.

Our protocol will become a fierce competitor in the sphere of regulatory-compliant payment. In the traditional banking system, whenever a client tries to open a bank account, the first thing the bank staff will ask for is his/her identity card as the client's identity is the foundation of regulation-compliant operations. In the Web 3.0 world, the HRIs will serve as the basis of regulatory-compliant finance. Faceless satisfies two vital requirements of regulatory compliance: 1. HRI will serve as the basis of regulatory compliance, 2. our payment solution will be private, which addresses a central issue in any regulatory-compliance requirement. One's HRIs such as social media accounts or PNS accounts can serve as the foundation to implement various regulation-compliant operations such as anti-money laundering. More sophisticated applications such as trusted decentralized finance (DeFi) can also be built on top of our system. For instance, one could build a credit system or lending and borrowing system based on one's HRIs.