Neo Address Resolution

[erikzhang]

No description provided.

[steven1227]

Why not put Neo addresses in NNS directly?

[erikzhang]

Why not put Neo addresses in NNS directly?

As I've answered in neo-project/neo#2284 (comment):

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]

NEP-1 as it is now:

If the NEP collaborators approve, the NEP editor will assign the NEP a number, label it as Standards Track, Informational, or Meta, give it status "Draft", and add it to the git repository.

Once the NEP is ready for the repository, the NEP editor will:
...
Merge the pull request...
List the NEP in README.mediawiki

But we have this one, #134 and #145 with an "Accepted" status, listed in README and yet not merged into the repository. Is this correct from the process POV? I think we should merge them at least. If any changes needed they can be done in separate PRs until these NEPs reach "Final" status. And then "Final" NEPs MUST NOT be touched except for grammar, spelling, or markup mistakes. Maybe we want to update NEP-1 with this?

[Jim8y]

@shargon should we merge the accepted proposal?

[shargon]

@shargon should we merge the accepted proposal?

Yes, we are all agree? please vote with 👍 or 👎

[roman-khimov]

We will provide some examples afterwards, we're storing contract hashes in NNS already.

[vncoelho]

And where is the domain name?

[vncoelho]

This is just for the address themself? no directly relation to the domain that will be linked, right?

[shargon]

@roman-khimov maybe we should use address.N3= ?

[roman-khimov]

I don't think it's worth the trouble. Legacy is almost non-existent to me and it's easily separated from N3 because of A prefix.

[shargon]

I don't think it's worth the trouble. Legacy is almost non-existent to me and it's easily separated from N3 because of A prefix.

But you can store ethereum address o bane address also...

[cschuchardt88]

I think this should function like DNS.

I don't think it's worth the trouble. Legacy is almost non-existent to me and it's easily separated from N3 because of A prefix.

But you can store ethereum address o bane address also...

The hostname for the txt record would be whatever format the validator wants. This would provide ownership validation.

Example

hostname	Record Type	Value
ether-challenge	TXT	"address=0x26FfB57236FeA81746c9a1f2604fEB7ec1Bb4BDC"

[roman-khimov]

But you can store ethereum address o bane address also...

The way the NEP author wanted it is #133 (comment). To me it's acceptable, having this standard as it is now it better than not having it at all.

[superboyiii]

Better than nothing. Let's vote for merge. @shargon @roman-khimov @AnnaShaleva @Jim8y @shargon @AnnaShaleva

[Jim8y]

Man, you have to tell us how to vote @superboyiii

[vncoelho]

How to vote neutral as well? For me this is kind of neutral.

[Jim8y]

How to vote neutral as well? For me this is kind of neutral.

yes or no man please, decisions must be made.

[Jim8y]

But isn't this one already marked as accepetd?

[cschuchardt88]

After this can we make reverse lookup for new type PTR

[AnnaShaleva]

Definitely worth merging, it might be helpful for NeoFS.