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)

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

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?

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

• 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)