Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Account Name Service #968

Closed
ilblackdragon opened this issue May 26, 2019 · 4 comments
Closed

Account Name Service #968

ilblackdragon opened this issue May 26, 2019 · 4 comments
Assignees
Labels
C-epic Category: an epic

Comments

@ilblackdragon
Copy link
Member

Implement Account Name Service: system that defines how new accounts can be called.

High level design:

  • To register Top Level Name: ".near", ".com", etc - you need to burn some number of NEAR tokens (the shorter the name, more tokens it costs).
  • Any account can create sub-accounts that are prefixed by this account. E.g. account "gmail.com" can create "blah@gmail.com" or "blah.gmail.com".
@ilblackdragon ilblackdragon added this to the TestNet 2.0 milestone May 26, 2019
@ilblackdragon ilblackdragon added the C-epic Category: an epic label May 26, 2019
@eriktrautman
Copy link
Contributor

Adding comments from on-desk chat yesterday.

Re: TLDs Basically, making a full with-TLD name the default (eg foo.near) seems like bad UX since users will always be redundantly typing the .near part. I get that we're trying to allow TLD registrars to set up specific criteria for handling all names that are registered within their namespace so they can defend against squatting on legitimate names (eg Google may want to register the .google TLD and guarantee that each sub address matches to a gmail account ((ok, ignore that we may violate the dot-naming convention here))). But users will hate it... and we're in a virtual world that's been comfortable for a long time with using handles and acknowledging that a handle doesn't always correspond to that person (eg a celebrity)'s real identity. So let's just make normal handles without . the default, ignoring squatting issues, and use the . TLDs to denote specific registrars who can have their own state criteria.

Re: Protected keywords Seems like the easiest / not-overengineered solution to reserving keywords is just hardcoding an index of blacklisted usernames like admin near etc.

@evgenykuzyakov
Copy link
Collaborator

@eriktrautman So basically . would be a restricted character in the account ID. And it can only be used with domain-style names. Is it correct?

@eriktrautman
Copy link
Contributor

eriktrautman commented Jun 7, 2019 via email

@ilblackdragon ilblackdragon modified the milestones: TestNet 2.0, TestNet 2.1 Jul 2, 2019
@evgenykuzyakov evgenykuzyakov self-assigned this Aug 19, 2019
This was referenced Aug 19, 2019
@ilblackdragon ilblackdragon removed this from the TestNet 2.1 milestone Aug 29, 2019
@evgenykuzyakov
Copy link
Collaborator

Implemented

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-epic Category: an epic
Projects
None yet
Development

No branches or pull requests

3 participants