Web3.js in status app

Archive
1

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:

Screenshot%20from%202018-08-03%2016-05-55
Screenshot%20from%202018-08-03%2016-05-551212×603 27.9 KB

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.

You can see that the web3 provider communicates directly with status-go through the rpc url on localhost. Our web3.js provider is 100 lines of Javascript that implement the same methods available in the HttpProvider of web3.js 0.20, which should still be compatible with version 1.0 of the library. The HttpProvider is however marked as deprecated in the latter version.

Within status react the web3 object that is used everywhere is actually a simple javascript object that has a sendAsync method, which uses status-go call-web3 method.
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

Arguments

Data oriented: synergie with extensions and status-api
Testability
Simple
Less indirections
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

Proposal

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.

Let’s discuss!

2

Can you please elaborate what “wrong” mean?

Also, in the graphic it says that “web3 provider” in a webview calls “Localhost RPC” but in fact it calls “CallRPC” binding, right?

It looks like replacing the internal “web3.js” usage will require building quite a lot of abstraction. Even if we introduce bidirectional communication between status-go and status-react, some abstraction will be needed.

I am down with implementing a bidirectional communication between status-react and status-go but I don’t see advantages of replacing web3.js as still a lot of abstraction would need to be built.

Have we tested upgrading our internal web3.js to 1.0? And the second thing, could we only use web3.js internally that always uses CallPrivateRPC so that there are no exceptions? Is that safe or there are some extensions that would require a different instance with a different provider?

3

yes, we have misleading leftovers in our code, actually, we call “CallRPC” binding directly from webviewbridge native code, and do not use http address

Finally Status API is a completely different

Let’s call it Status JavaScript API Status - Make the jump to web3

4

Hi @adam @yenda

My name is Graeme Barnes, I’m a new PM here at Status. The web bridge/Javascript API is super powerful. Has anyone in the community built or played around with triggering responses in chat via a Dapp?

5

Hey @Graeme !

The web DApp API is still in its infancy and currently only exposes the whisper key. you can find more details here

1 Like
6

Fixed, I meant that the dapp didn’t import web3.js library.

It is hard to tell without giving it a try, but I think it is relatively straightforward.
The idea is to first check for feasability. I think we will first do it for contracts calls, which is less abstraction than going through web3.js. We only need to implement the abi spec, and call status-go call-web3 with the right payload.
We can do that very iteratively and eventually keep web3 for things that would end up being too complex to do without it.

Indeed my local version of webview-bridge was outdated, I see it after pulling the latest. But I’m not sure we need to go through this, couldn’t we simply use the bridge and go through status-react like we do with Status JavaScript API ? This would potentially allow us to also use permissions for web3.

We don’t expose whisper api through web3. But with Status Javascipt API we can eventually expose chat features in the future