Metamask-extension: API for dapp to request network change

Created on 20 Aug 2018  路  20Comments  路  Source: MetaMask/metamask-extension

Hello,

I would like to connect a metamask user to a custom network directly from my dapp.
The idea is to avoid the user to have to copy the new custom RPC url and paste it in a second page metamask form.

Context :

Today when a dapp running on a custom Ethereum blockchain wants a user to sign a transaction, the user needs to :

  • Copy the custom url
  • Open Metamask
  • Click the dropdown menu
  • Click the parameters button
  • Search for the 芦聽New RPC URL聽禄 form
  • Paste the url
  • Realize that the other form fields has no connection and are not needed
  • Click the save button
  • Click to the cross to go back to the main menu

And this a very long process. And metamask does not always remember the custom network.

My proposal :

The web3 metamask provider accepts a new function to add a custom RPC from the dapp.
The metamask extension shows a window to warn the metamask user that it鈥檚 network has been changed. The warning should be enforced if the chainId is 1.
The dapp can ask the user to send a tx to the custom network using eth_sendTransaction.

What do you think about this feature ?

L27-Permissions

Most helpful comment

Does it mean a dapp can ask the user to sign a tx on Rinkeby (or any other network) while his current network is the main network ?
And the opposite ? This last one might be tricky for the user.

Long term, I think the concept of "connected network" will become less meaningful. What is more important are the assets you hold. Some are test ether, some are real ether. If we represent the asset being transferred correctly, we should be able to provide a good inter-chain dapp development experience without exposing the user to unusual phishing risks.

All 20 comments

Hi there,

I am really insteresting in developing the feature myself and share it with the community, but I would like to be sure it has a real chance of being accepted.

cheers

@etienneroudeix I think this proposal makes a lot of sense. We've discussed this internally a couple times and would love to collaborate on a solution.

This could be a good candidate for an EIP, and will likely have some downstream effects on the Custom RPC UI we show in our settings menu.

See https://github.com/MetaMask/metamask-extension/issues/3604 https://github.com/MetaMask/metamask-extension/pull/5134 https://github.com/MetaMask/metamask-extension/issues/3512

cc @danfinlay

This is very aligned with my general thinking of MetaMask going forward. For example, it is reminiscent of how we have begun addressing managing a list of tokens:
https://ethereum-magicians.org/t/eip-747-wallet-watchasset/1048/9

Once we merge support for custom chainIds, we could begin implementing this.

Two open questions from that PR:

  • Where do we get prices for a custom chain?
  • What block explorer do we link to for a custom chain?

Both of these things (prices & explorer links) have previously been neatly trustless parts of MetaMask (you can cross-check what a Dapp claims against them). If Dapps could propose networks, how would we answer these basic questions?

@danfinlay I would like to know the eta schedule for optional chain id support , it has been open from 12 days ago and still no sign of review or merge 馃槀

@bdresser @danfinlay Thank for these answers and the referred issues/PR links.
I'm glad MetaMask wish to move in this direction.
If Dapps can propose networks, it must/should provide any element Metamask needs, like the block explorer link patterns for block/tx.
Concerning the currency converter it is indead a bit more complicated. But the convertion is already not shown for testnets and custom RPCs. So I think it is an unrelated issue.

Hi, the EIP-2015 looks really nice for UX.
I need an easy way to ask the user to switch between chains, as described @etienneroudeix the current process is really painful and this EIP will help a lot for the user adoption.
@bdresser Is there any plan at MetaMask to work on this feature?

Yes, we're looking forward on integrating an API for suggesting network change, but we currently think it might be more appropriate to either/both:

  • Integrate it into the initial sign-in prompt (.enable())
  • Allow additional network providers to be requested at will (allow multiple network connections without user confirmation).

We are doing work towards both of those right now, and while this might be slightly lower-hanging fruit, these solutions seem more beneficial long-term. Thoughts?

hi @danfinlay

Allow additional network providers to be requested at will (allow multiple network connections without user confirmation).

Does it mean a dapp can ask the user to sign a tx on Rinkeby (or any other network) while his current network is the main network ?
And the opposite ? This last one might be tricky for the user.

Does it mean a dapp can ask the user to sign a tx on Rinkeby (or any other network) while his current network is the main network ?
And the opposite ? This last one might be tricky for the user.

Long term, I think the concept of "connected network" will become less meaningful. What is more important are the assets you hold. Some are test ether, some are real ether. If we represent the asset being transferred correctly, we should be able to provide a good inter-chain dapp development experience without exposing the user to unusual phishing risks.

Could we first add a feature allowing the dapp to query the address of the node it is connected to, in addition to being able to get the chainID? This is much more important for custom RPC addresses. The user can see what's there, but the dapp currently cannot, and this reduces usability by adding failure paths that are not intuitive for users to debug, even/especially when they can verify that dapp files (e.g. HTML and Javascript) are coming from an expected server.

Some RPC URLs include private authorization keys as query parameters, so I'm not sure I'd want to leak that information to every site a user visits. I would hope providing chainId/networkId checks as well as the ability to suggest a specific RPC would satisfy most applications' needs. If checking the exact URL of the user's RPC were really necessary, I would be inclined to provide it as an additional sign-in permission, so the user would explicitly grant that information disclosure.

How would a dapp know if it needs to request a network change, if it doesn't know what it's on?
Maybe a feature to get an accurate answer to "Am I connected to RPC URL \

For the time being, the networkId and chainId parameters can be used to identify EVM-based blockchains, and should be used instead of an RPC, since a user may choose to connect to a given blockchain with their own / a custom RPC.

any update on implementing EIP-2015?

We are currently putting more effort into EIP 2255, which will eventually incorporate the parameters from EIP 2015, but allowing the wallet to connect to different networks on different dapps, instead of preserving the fairly broken notion of a single network for all browser tabs.

Any estimation when EIP 2255 (which will implement EIP 2015) will implemented? looking forward adding better network switching for our Metamask users.

Hi @danfinlay any ETA for this function to be supported? looking forward to it

I see here that EIP-2255 has been integrated into the browser version
(https://docs.metamask.io/guide/rpc-api.html#permissions).

_"Currently, the only permission is eth_accounts, which allows you to access the user's Ethereum address(es). More permissions will be added in the future."_

Is the proposed EIP-2015 functionality still planning to be incorporated as a permission call? If so, is there any idea when this may be?

Was this page helpful?
0 / 5 - 0 ratings