Multiple whisper and wallet keys

Agree with it. The “upgrade” opt-in should be designed and prepared to future upgrades to Universal Logins.

I think needs to be define how this multiple whisper keys and multiple wallet keys will be used to interact user with network. I am not discussing how this keys would be derived (and if they should be). My description here is for the final vision and we might need to start with small bits to fit the entire vision of account system.

Wallet and Messaging keys right now are the same, just differently purposed, which I think is fine.
Wallet key: is well described here https://kb.myetherwallet.com/private-keys-passwords/difference-beween-private-key-and-keystore-file.html
and is used by Status exactly how it’s now: sign sendTransaction and sign requests from web3.
Messaging key: would be keys that it’s signature is not used in ETH blockchain.

Account system would be enabled by an extension.
Account is a smart contract that can sign in chain actions, such as “MultisigWallet.sol” and “Identity.sol”.
When user selects an Account a extension would capture and process sendTransaction and sign requests. The internal web3.sign and web3.sendTransaction could only be signed for authorized keys.

Wallet keys: are used in execute from Account, the hash of public address is publicly visible with the Account.

Messaging keys: the keccak256 of public key could be listed as an encryption key, enabling the use of usernames in chat messages owned by Account.

When user authorizes dapp to see their wallet key, the Account extension gives a unique address for each dapp.
Dapps would be able to customize the authorization process, because some would require “CLAIMS” to be used, or use a smart contract to interact with the user account (as example subscriptions).

Status public chat could use Account to send message, in this case an associated encryption key would be used to sign the message, another message could say the account contract address, which this signing key should match the keys listed on that account contract as encrypton key.

Status private messages could use Account as first handshake with tribute to talk.

take a look at @iurimatias post Status.app some very interesting economics to model