Account Name System

[ilblackdragon]

No description provided.

[ilblackdragon]

Added new pricing model for accounts suggested @evgenykuzyakov : additional storage rent is added for short domains.

[bowenwang1996]

Is this the per byte price?

[ilblackdragon]

no, this is just an extra storage rent for this account.

[ilblackdragon]

Offline @DanielRX suggested:

Would a prefix like npm does it (@near/) not work better?
@near/illia vs illia.near

I would say near.com/api implies api is a subset of near.com more so that api.near.com as the namespace comes last.

reallylongname.otherreallylongname.otherotherreallylongname.domainwecareabout
Vs @domainwecareabout/otherotherreallylongname...
Plus, normal users see C:/UserName/Music more often than a domain name system
The key thing I'd say is some form of separation is absolutely needed

My first reaction that inverted order is less expected for regular user, because most of the times you care about the actual username / name "illia" vs the namespace "near".
Obviously for developers "x/y/z" is a common occurrence, but if we think of mobile users - file system is not a concept for them.

[DanielRX]

An actual key thing to note is this: the order makes 0 difference. We just need to have something, as the order can be swapped later on before Mainnet or even just on ui tools.

One thing I think would be essential is that namespace or sub domains are default

So if I make an account x, then that makes an account y, it is created at x.y, not y

[DanielRX]

So, to fully formalise what I am talking about, I will add it here for @ilblackdragon and @bowenwang1996 to review and I can open a full issue if needed

At present you have accountId which will be named root in the system below:

We define 3 accountId types:

all = root | sub
root = oldAccountId (5 - 32 a-z etc)
sub = root "combined with" all

I use combined with as in-protocol it could be stored in a million ways
The focus on this issue should be completely disconnected with how a root and sub get combined, but only on how a root or sub accountId works

Having some form of sub accounts is clearly something you want, and has many benefits, so I think the key here is to change the issue to be independent of any formatting and focus on the features of the sub-domain/name system.

The key rules:

Only X can create an account with X as the sub part of the account
(only stardust can create stardust&danielrx)
Each root element (stardust and danielrx in the example) must adhere to the same rules (5-32 a-z etc) as a root account would.
Since the separator character would be banned from the root name charset, it would implicitly force the sub name to exist first (stardust can't create stardust&danielrx&main, it can only create stardust&danielrx which then can make the full name)

I think the protocol should start off independent of the format, and just hold part1, part2, part3 of the name, and the UI can be adjusted to support any format (or be made so that the user can decide)

[evgenykuzyakov]

Discussed with @ilblackdragon the following rules:

Rules:

• minimum length is 2
• maximum length is 64 (bumped from spec)
• Account consists of Account parts separated by a separator
• Account part is lowercase alphanumeric and _-
• Separator is either . or @
• Anyone can create a top level account (TLA) without separators
• Only X can create a sub-account: account_part separator X, e.g. only com can create google.com or abc@com. NOTE: com can't create images.google.com directly.

Regex (ignoring total size):

• Account part is [a-z\d\-_]+
• Separator is [\.@]
• Account is ([a-z\d\-_]+[\.@])*[a-z\d\-_]{2,}

Open question
Should we allow consecutive - and _ or whether they should only be within sub-accounts, and not start with them or end with them? E.g. alex-skidanov is ok, but ___illia---blackdragon___ should not be.

Examples

OK

• bowen
• ek.near
• google.com
• bowen@google.com
• illia.cheapaccounts.near
• 100
• over.9000

OK RIGHT NOW, BUT QUESTIONABLE

• ---ek---
• __--ek--__
• __
• --
• -.--
• __.__

NOT OK

• @@@@@
• a
• BRO
• @lol
• a..near
• hello world
• abcdefghijklmnopqrstuvwxyz.abcdefghijklmnopqrstuvwxyz.abcdefghijklmnopqrstuvwxyz
• what@
• what@a

[icerove]

min len could be 5 or 6, 2 is too short? not all number, at least one letter?

[evgenykuzyakov]

short names are mostly for TLAs and they are expensive to own if you don't monetize them, e.g. com, us, cn, borsh

[ilblackdragon]

Let's just not allow [-_]+ and (^[-_].*|.*[-_]$)

[evgenykuzyakov]

Update

• Account Part is now ([a-z\d]+[\-_])*[a-z\d]+ which means you can't start a sub-account with - or _, you can't end it with - or _ and in the middle you can have at most 1 consecutive separator of - or _.
• Total regex (excluding length) is (([a-z\d]+[\-_])*[a-z\d]+[\.@])*([a-z\d]+[\-_])*[a-z\d]+

OK

• a-a
• aa
• 0o0ooo00oo00o
• 10-4.8-2
• no_lols

NOW NOT OK

• ---ek---
• __--ek--__
• __
• --
• -.--
• __.__

[evgenykuzyakov]

UPDATE on rent

• Formula for rent is still 1,000 / (3 ^ (account_id.length - 2)) per year for account IDs with at most 10 characters. But it's calculated based on the constant in the genesis per block. E.g. if we estimate the number of blocks per year to be 31536000, then the base constant in the config will be

1000 * 10 ^ 18 / 31536000 = 31709791983764 (in atto-near)

So for bob.near the rate per block will be

31709791983764 / (3 ^ (8 - 2)) = 43497657042 

Which is about 43.4 * 10^-9 tokens per block.

For short name like com:

31709791983764 / (3 ^ (3 - 2)) = 10569930661254 

Which is about 10567 * 10^-9 tokens per block.

• Short name rent is charged as a premium in additional to basic cost per byte. It doesn't replace the rent for the storage of the account_id. So ek will be charged for 2 characters storage in addition to the short name rent. But if the account ID length is above 10 characters, the premium is not charged.

[DanielRX]

If you are going to have rent on names, would it not make sense to allow for the root to choose to pay the rent for sub names?

Then if you had bob.near, alice.near and near, near could opt to pay the rent with its balance for bob.near and alice.near. This would also make it simpler for owners of lots of addresses, since they can fund (and calculate funds) with one account, instead of sending dust to each account to keep it going.

[evgenykuzyakov]

Rent is used to prevent squatting short names with the only purpose of reselling them later. The rent can be avoided by having a longer name, e.g. 11 characters or more. The actual constants will likely be adjusted once we know the reasonable price for the short account names.

[evgenykuzyakov]

We've decided to restrict @ from the account_id. Then we can use twitter style handles like @bowen.near

[icerove]

at that point, as I tried, our instruction for wallet create account page should be more clear instead of just user name is taken, try something else.

[evgenykuzyakov]

@ilblackdragon I think we can close this? It's should be merged in the spec already

[ilblackdragon]

Correct @evgenykuzyakov
Closing this, as it's already in the spec https://github.com/nearprotocol/NEPs/blob/master/specs/DataStructures/Account.md#account-id-rules