Neo: Support storing NEO addresses in NNS contract

[roman-khimov]

Summary or problem description
NNS currently defines records of types A, CNAME, TXT and AAAA for names which roughly mimic regular DNS types. So we can resolve some name into IP (v4 or v6) or opaque text record effectively. What we can't do is resolve it into some NEO address which I think can be useful for "send some GAS to whatever.wallet" scenarios where whatever.wallet can be resolved via NNS into some NUVPACMnKFhpuHjsRjhUvXz1XhqfGZYVtY NEO address. See #1179 and #1450 also.

Do you have any solution you want to propose?
Add "NEO" record type to store (syntactically checked) NEO addresses.

Neo Version

• Neo 3

Where in the software does this update applies to?

• Other: NNS contract

[erikzhang]

I thought about this problem. But I find it a bit strange to bind NEO addresses directly to domain names. It would be nice to bind to an email address.

[shargon]

But I find it a bit strange to bind NEO addresses directly to domain names.

I think that precisely a named service in blockchain it's for store this information.

[erikzhang]

I found some scenarios, such as Dapp domain name can be resolved into Neo address. We should propose a standard that uses TXT records to store addresses.

whatever.wallet   TXT   "address=NUVPACMnKFhpuHjsRjhUvXz1XhqfGZYVtY"

This way we don't need to modify the core.

[roman-khimov]

TXT can be anything, adding a proper type is easy and it will help us ensure that the thing in this record is actually a valid address.

[erikzhang]

Please check neo-project/proposals#133

[roman-khimov]

Look at it from the perspective of NNS user. I want to know if whatever.wallet can be resolved into valid address.
1) With proper type. I make a resolve query, if there is a record I get a result, if there is no record I don't get a result.
2) With TXT. I make resolve query for TXT, I may get it or not. If I've got it, I need to parse it and check if it conforms to some address=smth expectation. If it does, I need to check smth for basic address validity. So we have way more error conditions that every client will have to check for.

This TXT thing is good for independent experimental features, but NEO addresses seem like a core concept to me.

[erikzhang]

But these steps are done by the wallet or client, the users don‘t need to perceive it.

[erikzhang]

My design philosophy is to design a lightweight core as much as possible. For problems that can be solved with standards, try not to add functions to the core. Unless this can bring very obvious advantages, such as performance improvements.

[roman-khimov]

Following this logic we might as well strip it down to TXT and CNAME only (even to TXT only with a little more effort). Yet we still have A and AAAA. And for blockchain use case NEO record type (or its TXT equivalent) is expected to be used more frequently than AAAA and probably even A, just because that's what people care about when they're using Neo. A and AAAA records don't make their $BROWSER suddenly use this data, while NEO addresses are expected to be supported by every wallet implementation.

So it'll sure work with TXT (and neo-project/proposals#133 is useful for other purposes), but it doesn't look like an optimal choice for addresses to me.

[erikzhang]

NNS is the domain name service on neo. The main application scenarios of A and AAAA are neofs. In the future, the dapps front end will be deployed on neofs, and the contracts will be on the mainnet. This requires the use of NNS for domain name resolution. This can be completely decentralized, which is the embryonic form of the next-generation Internet.
Currently, there is no standard for domain name resolution of blockchain addresses. It is safest to put in TXT record without any side effect. I think the relevant standards will definitely be published in the RFC in the future, and then we will follow the standards again. If we do something special now, it won't be easy to change then. With neo-project/proposals#133, it is equivalent to letting NNS support address resolution. This will only bring benefits and no harm.

[roman-khimov]

I'm not sure I'm convinced, but probably the main thing here is to have this use case covered one way or another and as neo-project/proposals#133 does this, so be it, we just need to add support for it everywhere.