[Draft] Ensure EIP1102 compatibility

[rachelhamlin]

Wallet code will no longer be accessible by default after EIP1102 is forced as a breaking change.

User will be required to grant permission for this as well.

[3esmit]

When this is going to be implemented in status? How the Dapp can check if the current web3 provider is EIP1102? Perhaps if no account address is provided then it should consider EIP1102?

[rachelhamlin]

Not until the week of 19/11.

We decided to punt it until OKR voting was finished so as not to break that DApp. Embark team has some further work to do to support it elegantly and the EIP has changed again multiple times as well, as have other teams' roll-out strategies.

[jeluard]

@3esmit @bgits Most of the work will be abstracted for us by embark.
A DApp should assume EIP1102 is available and be modified accordingly as all browsers are pushing it as default and the old method will be deprecated soon.

[3esmit]

What the next step for implementing this?

[rachelhamlin]

EIP1102 is now optional for users with browser privacy mode.

There is an Embark update coming in the next ~2 weeks that will allow you to trigger the request based on user action, rather than during app initialization. When that's available, we should integrate EIP1102.

@iurimatias any update on that user story 3?