While my presentation was mostly talking about the state for web3.js itself, I would like to focus more on how Status uses web3.js and question the reason for doing so.
First let’s illustrate the current state of web3.js within Status app:
The proper interface between Dapp code and browser injected code is the web3 provider. Dapp must use their own web3.js library, to avoid incompatibilities between the version they are developped for and the one that would be otherwise injected by browsers.
In Status we only inject web3.js if the dapp doesn’t have it, so it was ignored in this schema.
There is one exception where
call-web3-private is used instead and doesn’t go through web3 but prepares and sends the json-rpc payload directly.
Finally Status API is a completely different thing that uses the webview bridge to communicate with status-react. It is used to offer functionnalities that are not part of web3.js such as providing the whisper address of the user, and ask permission to the user before letting dapps access these functionalities.
So as I tried to explain in my talk and everyone hopefully understood, there is actually 2 potentially different web3.js used in Status.
- one that only interacts with status-go through our web3 provider via http calls to localhost. We can keep it that way because new dapps should use their own web3.js.
- one that is used as a library by status-react. This discussion is about replacing it.
Various use cases for web3.js in status
- transactions: very simple call
- wallet related calls: erc20 and erc721 management are actually interactions with contracts
- interactions with contracts: simple rpc calls, we need to either start using web3.js eth-abi package or implement a proper version of the abi-spec to support dynamic types if we want to be able to interact with all contracts. So far we only had to deal with static parameters. Reads are eth_call, interactions are eth_send_transaction
- whisper: complex calls, web3.js does some heavy lifting abstracting the lack of bidirectional communication in json-rpc by polling regularly for new messages for each filter
- misc: current block, networkid; simple calls
Data oriented: synergie with extensions and status-api
Better comprehension of Ethereum interface
Things that we still need to clarify
- test if our current web3 provider works with dapps that make uses of promises in web3.js 1.0.
- establish a bidirectionnal communication channel between react and go (bindings + signals ?)
- how this fit with the old and new transaction flow @andrey
- progressively remove the use of web3.js in status-react to favor direct calls to status-go
- design a data-oriented way of declaring abi spec and implement it
- implement json-rpc and json-rpc pub-sub in status-react
The first step is to decide if it is worth it (I think it is)
The second one is to agree on a draft of the data-oriented abi declaration and json-rpc usage
Then we can start gradually implementing.