Get all Ethereum accounts from Metamask

[vmundhra]

Metamask always returns only one address and not all the accounts that a user has added. I tried all web3.js methods to get accounts, but I always get just one account which is always the currently selected one.

According to web3.js documentation, web3.eth.getAccounts() should return all accounts that this node controls. However, I am getting an array with just the currently selected one. Needless to say, I have multiple accounts created in Metamask.

[bdresser]

For privacy reasons, we only expose the account the user has selected. It would be pretty shady if we let any site request every single account address in your MetaMask.

in the future, we won't even expose that one account by default; dapps will need to request access to the account by calling ethereum.enable(). See https://github.com/MetaMask/metamask-extension/pull/4703 for more detail.

[levity]

What about if the user has allowed access to multiple accounts? For example, say they allow access with ethereum.enable(), which shows their currently selected account, then they select a different one. Let's say the dapp they're using is keeping track of this and so now knows about both accounts, and wants to initiate a transaction from the first one, which is no longer selected. Would this behavior ever be supported by Metamask?

[markusbkoch]

@bdresser can we reopen this for increased visibility and further discussion, or should we start a new issue on the same topic?

What problem are you trying to solve? I want to know how much value is stored in a wallet, by account and token

Describe the solution you'd like Create an advanced setting for the user to choose to allow dapps to get all accounts, not just the selected one.

Additional context I understand the privacy concerns that lead the team to only expose the selected account. Some interesting use cases might be enabled by the feature, especially in related to portfolio management in DeFi IMO.

[markusbkoch]

For clarity, this is roughly what I have in mind when I say "value stored in a wallet by account and token"

Asset/Account	Account 1	...	Account N	Total
Ether	10	...	0	10(+...)
Token A	100	...	250	350(+...)
...	...	...	...	...
Token B	0	...	1000	1000(+...)
Total (USD)	x	...	y	z

This could be part of MetaMask itself, but I don't think it should. Instead, MetaMask should enable dapp developers to build this and more - the same logic applies to managing a portfolio of MakerDAO CDPs, Compound loans, Cryptokitties,... anything the user might be using multiple accounts for, whatever their reason for doing so might be (usually privacy), and where the action they're trying to take depends on evaluating all of those accounts simultaneously.

Like I wrote in the previous comment, I understand the privacy concerns that led the team to only expose the selected account. But if there's a setting to allow the user to choose to expose all accounts, it could be disabled by default. Advanced users would enable it only when interacting with dapps they trust not to log user accounts information on their servers (and local-only dapps), and possibly only through their own local node.

[danfinlay]

There is an opportunity for us to eventually make this possible using our very-soon-coming EIP 2255 permissions system, and we've discussed it a couple times internally. This is largely blocked by the UX of multi-account-log-in, so if anyone wants to suggest how this would work, that could contribute to our team buy-in: https://ethereum-magicians.org/t/web3-login-permissions/3583

[markusbkoch]

Thanks, @danfinlay. To clarify, the block is in how to design this screen (or a replacement for it) when the permission request refers to multiple accounts?

[danfinlay]

We have a few internal designs, but it turns out that once accounts<->sites is a many-to-many relationship, a lot of our UI assumptions go out the window. This feature requires a fair amount of re-imagining our experience, although we have some designs that make it possible with less work.

[markusbkoch]

UX is not my thing, but as a user I would be happy with something like this:

• Site requests permission to selected account
  • This is what you have in the permissions adventure GIF, it's great, nothing to add
• Site requests permission to all accounts
  • Metamask's confirmation window shows something like MetaMask's logo in place of the account icon and the text "all accounts" in the dropdown
  • Clicking the dropdown makes it easy to change the permission from all accounts to account X
  • There's a link in the confirmation window that takes the user to a view of the permission settings page (filtered by site and permissions being requested)
• Site requests permission to a list of accounts
  • Less common as the site can't know the list of accounts beforehand
    • Still useful if the site needs to ask for a new permission on previously approved accounts or if the user inputs a list of accounts before the request
  • Confirmation window makes it easy to see what accounts are the target of the request (maybe hovering the mouse over the "many" icon show a list of account names?)
  • Clicking the dropdown makes it easy to change the permission from all accounts to account X
  • There's a link in the confirmation window that takes the user to a view of the permission settings page (filtered by site and permissions being requested)

Bonus points for the ability to classify accounts as "public" and "private" (there might be better names for those classes), so that the dropdown in the confirmation window can also have options like grant access to all public and grant access to all but private at the top :-)

[danfinlay]

I'll share your ideas with the design team when we are looking at this next.

[0xrubes]

I am pretty shocked that there is no way to enable metamask to return all accounts (with the method named getAcccount>s<). We are pretty new to the dApp world and this is heavily restricting us in our current design of our dApp, which is supposed to give users roles based on their owned private keys. I would highly appreciate if you consider adding this feature.

[danfinlay]

I would highly appreciate if you consider adding this feature.

We're quite deep in this consideration, and I think you'll be pleased with just how soon this is likely to come: https://medium.com/metamask/metamask-permissions-system-delay-retrospective-9c49d01039d6?source=collection_home---4------0-----------------------