Client: Support opt-in provider access with connect button

[izqui]

Design

Current signers and wallets that inject the web3 object by default to all websites are leaking user information (sometimes even the addresses) that can be used for tracking purposes.

EIP1102 proposes a new flow for dApps to request a web3 provider by sending a message using postMessage, the user will then be prompted to decide whether to give the dApp access to web3. If the user accepts, a message is sent back by the provider to the dApp and a new window.ethereum object is injected (which is a web3 provider rather than a web3 instance). In case the user rejects the request, there is no callback or error sent to the dApp, so websites cannot identify a web3 user unless they give explicit approval.

On Nov 2nd Metamask and other wallets will stop injecting web3 and requiring to request access as specified in EIP1102 (thanks @jvluso for letting us now about the date for this!):
https://medium.com/metamask/https-medium-com-metamask-breaking-change-injecting-web3-7722797916a8

Assigning @jounih and @bpierre to decide what the best UX for this change would be. The article linked above proposes adding a 'Login' button to dApps, rather than requesting access when the dApp first loads. I think it is a good idea as it would prevent users rejecting the request due to confusion if the signer modal requesting access popped up on the first page load. If the user doesn't login or rejects the provider request the dApp would work as it does right now when no web3 provider is injected.

[jounih]

@bpierre what do you think about a "Login" or "Connect wallet" link at the bottom of the left nav? and showing "Connected to wallet" once logged in. Do we need "Logout"?

[luisivan]

I think a Login button makes sense. I don't like the term Wallet since what we mean is a web3 provider really (software like Frame is just a provider, doesn't handle funds like a wallet does)

[izqui]

Seems like the EIP has been updated https://eips.ethereum.org/EIPS/eip-1102

[sohkai]

An initial thought for this is to add a "login" flow to the signing panel, so that we only need to ask the user for approval if they want to send a transaction.

We could also combine this flow with #276.

[izqui]

An initial thought for this is to add a "login" flow to the signing panel

Until the user accepts access we won't have access to web3.eth.accounts, so we cannot transaction path. We need to ask for permission before.

[sohkai]

Assuming we think this would be the best flow (having it in the signer panel), aragon.js-wrapper could ask the client for accounts when it receives an intent but cannot transaction path.

[jounih]

Discussed this with @luisivan and @bpierre - we would like to have an area for user/network specific things in the bottom of the left panel. "Connect account" button, preferences icon and networks status

Prototype:

https://invis.io/MFOF866ET3N#/323903432_WebApp-1366px_-_Log_In

[sohkai]

We should make sure to be backwards compatible and feature detect that the user is using a wallet with the new window.ethereum interface, as well as if it has an window.ethereum.enable() method available.

[izqui]

Updated story of what will happen on Nov 2nd: https://medium.com/metamask/eip-1102-preparing-your-dapp-5027b2c9ed76

[sohkai]

In the context of responsive apps, the "connect" button would be hidden and may be quite difficult for someone to realize their account is still locked when inside an app.

This is also related to behaviour like #588, where users may be confused if an app locks up because no account is present.

A general guideline for apps could be to assume that a user's account is still locked if no account is detected, and for them to only disable actions if the current account has been determined to not have the requirements to invoke them. When trying to invoke an action with a locked account, the signer panel should open and allow them to connect.

[sohkai]

Implemented in #693.