Web3.js WhisperProvider. Sign with Status everywhere!


Currently, the only way to browse Decentralized web applications on the desktop is to use specific tools, browsers or extensions. What if it were possible to browse DApps and sign transactions on every web browser safely and even on someone else’s devices.


First of all, it should be super simple to incorporate it in currently working DApps, literally one line of code. To interact with Ethereum blockchain DApps use Web3HttpProvider with the web3.js library, so we could introduce JS library which provides WhisperProvider and communicates with blockchain through whisper messages. Also, this library should establish a connection with the Status app, let’s see how it may work.

If there is no access to the web3 object, means a user has opened DApp in a usual browser without web3 support, DApp could show an option to connect through the Status app, something like


Library will generate a new ethereum account and show QR code. A user will scan this QR code in the Status app, and whisper connection between user account in Status and library account will be established. After that user can browse DApp and when it will be necessary to sign the transaction, he will receive a push notification on his phone, open Status and sign transaction.

Technical details:

  1. JS library
  • WhisperProvider
  • Managing accounts
  • Connect to Status
  • Whisper messaging
  1. Whisper HTTP endpoint
  • Propagate encrypted message into whisper network
  • Return encrypted messages by topic
  1. Status extension
  • Scan QR
  • Communicate with library
  • Sign transactions
  1. Communication protocol between library and Status

It looks related to WalletConnect ?

Yeah, it looks related, but major differences are:


  1. Uses centralized bridge server
  2. Requires from Dapp to write and maintain code for sending txs


  1. Works over whisper
  2. Used in Dapp as usual Web3Provider

I wonder if WalletConnect is flexible enough top adapt to your proposition.

I wonder about a few things:

  1. How can a DApp send messages to Whisper? In order to do that, a Whisper node needs to have a key pair and that means that DApp’s author needs to run that Whisper node and properly secure communication between the webpage and the node. This is non-trivial and will make the integration much harder but doable.
  2. Another situation is returning users. The described flow requires generating a new account whenever I open the DApp page but it should be also possible to have something like “I am already connected” and somehow reestablish the connection. Am I correct?

Yes good questions @adam

  1. Idea here is to generate key in JS and encrypt messages on client, that’s why we need HTTP whisper endpoint (similar to infura), which will provide something like sendRawMessage similar to sendRawTransaction, I’ve talked with @igor and @dmitrys they said this is theoretically possible. And also this API may be useful for Dapps to send whisper messages without running Whisper node.
  2. A partial answer to this question in the first paragraph, because we generate a new key each time we need to add and “trust” this contact each time we open Dapp

Thanks for the answers.

  1. Oh, I see. That’s an interesting idea to add shh_postRaw,
  2. I am afraid that it might be a source of confusion. Also, potentially, I will have a lot of this one-time keys added as contacts, right?
  1. We can manage this, and do not create contacts. It is something like Google Authenticator, each time you log in , you need to take your phone and enter code on the web site, here the same, you need to take your phone and scan qr

Ah that would be a totally separate flow that is indented to be ephemeral. Sounds good :+1:

Is it worth the UX tradeoff to just show a QR code at the transaction stage instead of at the beginning of the session? You remove the need for whisper but you lose out on the cool/easy push notification flow.

Isn’t there also an option for a completely in-browser whisper node? This would remove the need for infura. The code would have hard-coded bootnodes so the browser could easily find peers. IPFS does does this and they’re using libp2p which I understand is similar to whisper’s devp2p so perhaps it’s also doable?

Glad to hear you guys have been thinking about this. Someone just mentioned on yesterday’s meetup in Berlin about this thread and love to have guys join our discussion to build this into WalletConnect

WalletConnect’s goal is to improve UX for all wallets by tackling the communication between. Current implementation uses Bridge servers to relay messages between mobile and desktop. However we always wanted to make more decentralized and Whisper was one of our early proposals.


As of last night, at the meetup we discussed how we could move from the current spec to make it more transport-agnostic. I’m happy to see the current solution is looking very promising and I’m planning to move forward with it next week with v2.0 version.

Let me know what you guys think so far of the proposal and would love hear more from you on this project.