Target accounts before registration

[s8sato]

I think the point is the domain membership screening.
How should a new account apply for and be allowed to join a domain?
In terms of authority, there will be a gap between transferring one's own asset to a new account and registering a new account, especially in "private domain".
So as you pointed out, the admission process should be managed by a different authority than the sender of the first transaction that mentioned the account.

One idea is that each domain has its own admission policy as a trigger that "activates" a new account in response to the account creation event.
Admission policies may vary from domain to domain e.g.

• No screening
• Wait for approval of the domain owner
• Wait for approvals of m of n domain members

In any case, as I implied, I'm going to create a new issue on this and remove the 2nd commit from this PR

Originally posted by @s8sato in #4411 (comment)

[s8sato]

Related discussions so far:

• feat!: authenticate personal accounts by ID #4411 (comment)
• feat!: authenticate personal accounts by ID #4411 (comment)
• feat!: authenticate personal accounts by ID #4411 (comment)

[s8sato]

current implementation policy

struct AccountId(PublicKey)

struct Domain {
    accounts: Map<AccountId, Account>,
    // snip
}

struct Account {
    id: AccountId,
    domain: DomainId,
    // snip
}

• A provisional account is assigned to default domain
• Register<Account> is an instruction to change account.domain
• Unregister<Account> is an instruction to reset account.domain to default

background

It seems unnatural to expect a multihash@domain address before the account is allowed to belong to the domain.
multihash address for accounts would be ideal at the moment.
However, this implies Map<AccountId, Account> directly under the world.
I'm not sure if a single top-level storage can withstand billions of accounts that Iroha ultimately aims for.
I'd keep the accounts map under each domain, accept both multihash and multihash@domain input, and convert multihash to multihash@default.
A drawback would be that address must include not only ID (multihash) but also domain

[Erigara]

I'm not sure if a single top-level storage can withstand billions of accounts that Iroha ultimately aims for.

Can't fully agree since when having all accounts in the one place we can better optimize their layout.
Also with our current Storage it's more beneficial to have more granular data.
Right now update in account imply whole clone of the domain.

A provisional account is assigned to default domain

What about permission interaction of assets and accounts?

Like suppose that we have some domain my_domain, and we have asset my_asset which is only allowed for account in my_domain.
We want to transfer this asset to offline account my_account.
On transfer my_account would be assigned to default domain and transfer would fail.
Do we want to support this case?

[s8sato]

Indeed, it can be misimplementation to equate the domain membership and the account activation e.g. someone can stash an account to another domain and an admin of the original domain can no longer revoke permission of the account.

Instead, domain (candidate) should be fixed from when the account is provisional.
Also, I'll consider shallow storages that maps account ids, in relation to implementing account activation

[s8sato]

• retitled to align with the original requirements described in New Account Structure #1594
• changed implementation policy as described in feat!: recognize and activate accounts #4668 (comment)