web3.js Integration in Wallets and Its Design

This is a thread which brings over a conversation from Telegram:

Victor:

https://github.com/MetaMask/metamask-extension/issues/7163

James Brown:

This is good. I favour having an absolute minimum injected framework and routing everything through the wallet. We can maintain the same JavaScript hooks, but that's all they'd be. It's worrying there's a huge body of source that we don't understand that we add to every webpage that is mostly unused

Boon:

The minimum they are talking about is actually the provider. They are still going to inject the provider — instead of calling it web3.currentProvider, it will be called ethereum (we already support both).

Check these out:

https://medium.com/@awantoch/how-to-connect-web3-js-to-metamask-in-2020-fee2b2edf58a

https://medium.com/metamask/no-longer-injecting-web3-js-4a899ad6e59e

Like I was trying to communicate previously:

web3.js works as 2 parts. The dapp browser provides web3.js version W and the provider P.

The dapp gets P (which provides the RPC node access) and can provide their own web3.js version D or just use the one provided by the dapp browser, W. In both cases plug P into W or D.

MetaMask has been talking about this change for a long time. The change is to remove W. P is still going to be around. Dapps will have to bring their own version of web3.js (or Ether.js) D.

And this is why customizing the bundled version of web3.js is the wrong approach.

The posts and issues also hints at why it was never a good idea for dapps to use W — incompatibility

James Brown:

Agree, this is essentially the direction that the changes I was making to web3.js are going in; bypass the processing done within the web3.js file and only provide a simple, cut down standard interface. It's too dangerous just bundling all the 3rd party JavaScript code in there. If we could distill the interface down to only what's needed it would be more deterministic. However as you point out we are constrained by dapp author expectation. There is an issue I spotted in the articles, namely that they have seen most dapp authors simply pull the credentials from the injected file and re use those. This isn't reliable and it would be very surprising if eg Uniswap used the credentials from the dapp browser, for anything other than checking the chainId.

James Brown:

ok. I had a quick look at the Uniswap source code. A few things - as you would suspect they have their own chain comms system backend, the other interesting thing they statically link the same icon source we use (Trust repo). The dapp is written in TypeScript. And there's a lot of it - consistent with implementing a full ethereum backend. It would be interesting to see how much of web3.js they use - probably only the wallet hooks.

I feel we should do the same to TokenScript. Actually I originally envisioned the <manifest> would allow matching JS libraries to be used (cached, shipped, not embeded) to be used in cards, including web3.js.

Note that this is what James said :slight_smile:

This is what I'm saying:

I agree to the sentiment and I think it's good to do that for TokenScript, but that is not how web3.js works.