With multi-accounts being released in Status v1, the user will be able to manage several accounts in his wallet. He will get by default (after onboarding, or recovering) a main account (m/44’/60’/0’/0/0) and will be able to easily add new ones. He will thus be able to manage his funds (check on them, send them, receive them) across different accounts from his wallet.
When a user engages with a dApp we plan to present this main account (m/44’/60’/0’/0/0) to the dApp.
For v1 we might:
1/ Not leave any flexibility to the user to change that, or
2/ Leave a more advanced user some ways to configure that and change the account presented to the dApp. e.g if the user want to interface with a dEX dApp with another account than his main account m/44’/60’/0’/0/0 because this is where he stored his funds.
From a design standpoint, we could do 2/ from several different manners
Let the user configure a « custom main account » setting that will affect several things across the app: the default sending adress from the account explorer, the sender adress when you « /send funds» from chat etc., and the account used with dApps,
Let the user chose at 'tx confirmation screen’ which account to use to sign the dApp tx, among the list of all accounts.
And, by the way, design will also need to address how the user gives his consent to share his account address with the dApp.
From a technical standpoint, and to further evaluate all aspects of whether we go for 1/ or 2/, your feedbacks on the following point would be useful:
What are the consequences of allowing the user to change the account that signs a dApp transaction, especially after the dApp has already started interacting with our browser? one example: I start interacting with a dApp, sign a couple transactions with my main account, and decide to change - either as a global setting before the transaction has been called, or at tx confirmation screen level after the transaction has been called ?
As per Web3 Tracking Tester I very much prefer the way status works now - clear all cookies on account switching. Same with switching addresses in dapp. Bonus points if we add randomized user agent string.
In this case I think we should decide before a dapp asks for a tx signature. As soon as the dapp asks for web3 permissions or calls web3.eth.accounts, we should decide which address we want to expose.
That’s a good point @Bruno because for now account switching means logging out and logging in back with a different “user”.
But with multi account, each user will be able to switch ethereum account withing the same “user account” without logging out, so maybe it’s something we need to consider to implement.
Definitely. I’d say err on the side of caution if we’re selling the true privacy angle of Status, which means don’t even allow the user to make the mistake of exposing their different accounts to a single dapp. I don’t expect people to use status to manage other people’s funds, which is the only scenario in which I can imagine not caring that a dapp knows it’s all me, so I think extreme caution and forced privacy is the way forward, especially because dapps can implement so much stuff on their own there’s no way to know what to expect from them.
It probably makes more sense not to allow to switch accounts when a DApp initiates a transaction as the from address has been specified by the DApp itself.
What has to be considered is which addresses should be added to the exposed accounts (JSON RPC · ethereum/wiki Wiki · GitHub , or with EIP1102 result of calling ethereum.enable())
For sake of clarity and simplicity, I’d propose we stick to one account only being presented to the dApp for now.
@gravityblast and @julien your feedbacks mean that the user should not change the account signing the tx after the dApp has called it. If we respect that (what would happen if not btw ?) we need some settings at the browser level (or status level) to define what is the account used to sign tx (if for v1 we go for option 2/ to provide some flexibility to the end user). In this case:
from a ux standpoint, the user would have to be able to chose this account on some browser or status settings, and be notified that his account his presented to dApps (privacy warning)
from a technical standpoint, can someone state what are the web3js (and cookies recommendations following @Bruno suggestions) implications when the user modifies his account ?
remark: In metamask, if I am logged in cryptokitty.com for instance with one account, and I change my metamask account among my list of accounts, I am immediately logged out of cryptokitty
we need some settings at the browser level (or status level) to define what is the account used to sign tx
Is there a concept of main address? And can it be modified?
web3js
Relevant implications are probably just implications at the JSON-RPC level, so nothing more than what I listed before.
remark: In metamask, if I am logged in cryptokitty.com for instance with one account, and I change my metamask account among my list of accounts, I am immediately logged out of cryptokitty
An account in MM is from a complete new seed AFAIK. If we expose only the main address, then it would make sense to do the same if this address is changed.
there is no sense to change account on tx screen, because dapp initialized with exact account, and all transaction initiated by dapp make sense only with this account, so in v1 we can just use one account, and later on browser level user can select account, and dapp will be reloaded with new account and cookies will be cleaned
example (trust wallet):
Definitely adopt Trust Wallet’s approach here - make it VERY easy to switch accounts while in app, but augment it even further by adding blockicons to the selector dropdown, MM style, so people can be immediately aware of with which account they are using the dapp in question.
This is right on the money. A dapp will do loads of interactions with an address much before it has had to issue a transaction. My suggestion is to open an account selection popup as soon as a dapp is opened. Something like:
This should also be re-summonable through a button next to the address bar, much like in Trust.
Granted, this is more friction in yet another thing to confirm, and could maybe be a setting that lets people pick “always default to account X unless I change it manually” to avoid this, but would make things easier for the privacy conscious among us. After all, people aren’t coming to Status for everyday chat - they’re coming to Status for private, safe, and censorship resistant interaction with web3 (and, yes, to chat).
Labels of accounts can be implemented just like with MetaMask - keep them in localstorage encrypted by the currently active private key, wipe on reinstall. They’re handy just for that one device, so the user has an easier time navigating between them, but don’t presume they’re permanent or easily transferable.
Looking to understand the UI implications of following the Trust wallet approach.
UI requirements
Account selection at a browser level
Account selection at browser level is always accessible for switching when browsing dapps
DApp permission request dialog includes reference to account selected at browser level
DApp permissions in settings includes a reference to selected account when a DApp was used
No account selection in transaction overview screen
What happens if I were to:
Open a DApp
Select at account for the browser
DApp requests, I give permission to access wallet address
I switch to another account for the browser
Would I simply receive the permission request again?
Does the DApp now have access to both wallet addresses or does the second overwrite the first?
A note that we need to consider the general direction of selecting accounts for chat here. The behavior is linked. If ‘select account for DApps’ means select at Browser level, it likely means select at Chat level for transactions in chat. It’ll be counterintuitive to follow different models for both. E.g. add an option to select account on the transaction overview screen for one and not the other.
You should get another request for access, yes. Status should clear cookies and local storage between account / address switches so dapp should not be aware of previous address. For best results, status should also randomize or standardize UA. I’m not sure how best to handle the chat aspect, but I do know that improper dapp masking is a huge unmasking vector.
