While experimenting with https://discuss.status.im/t/web3-js-whisperprovider-sign-with-status-everywhere/370 and discussing it, we found that it may be interesting to have Whisper API available over HTTP, it opens some new possibilities for Dapps and third-party apps or services. For example, apps could send messages to public or 1-1 chats.
It may work similar to Infura and eth_sendRawTransaction, something like https://api.status.im/shh_postRaw
We need to:
implement shh_postRaw in status-go , which will take an encrypted message as input and post it in the Whisper network
run HTTP server with API endpoint
implement JS library, which will be managing message encryption and posting messages via API
Additionally, port this JS library to other programming languages
I think it shouldn’t take a lot, because currently, we send Push Notifications messages from status-go, so we need just to add this to shh_postRaw, but in this case, apps should provide additional parameter - notification token
to whisper-api.sendPrivateMessage(account, "contact_code", "1-1 Message", "notification_token");
We use Firebase Cloud Messaging service for notification. On initial startup of Status app, the FCM SDK generates a registration token for the client app instance. This token is needed to be able to send FCM messages and notifications to the user’s device.
It looks like “bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1…”
So to be able to send notification to Status user you need to know his FCM token
I really love this idea because a) DApps want to decentralize their communication and protect user privacy. And b) User understanding of our mobile browser is fairly low. Core DApp flows that require communication with user via email, social or any other traditional means, boot them out of Status—and it can be hard for users to find their way back.
Example use cases:
When signing up for Peepeth, a user is directed to their email to activate their account with a confirmation link. This sends users outside of Status and forces them to copy and paste the link into our browser, if they know how. Peepeth could instead accept the user’s Whisper ID or ENS address and message them within Status.
Blockparty wants to notify users when they have funds to withdraw after an event. They currently use Twitter for this, but would rather be decentralized and send a push notification.
Bounties Network could ping someone when they have received a new bounty submission, or when their own bounty submission was accepted.
On the one hand, providing an HTTP Whisper interface (or WebSocket even) via a web server which would be stateless, i.e. it would not store Whisper keys, is a nice idea. On the other hand, this is actually a solution that brings centralization, as opposed to running independent Whisper nodes. It’s a similar case which we have with Infura: it’s a very nice service from the user perspective but it increases centralization.
A possibility for DApps to communicate with the Status app upon user’s action so that it’s not needed to open a different app to receive a message (signing up case); don’t we already have some mechanisms to do that?
An easy way to run some kind of “Whisper bot”. For example, when funds are available to withdraw in Blockparty, all participants could get a notification or a message. Here, we have two cases: (a) an admin who makes the funds available is responsible for sending the notifications/messages on their own or (b) there is a bot/watcher that observers a smart contact and sends the notifications/messages on behalf of blockparty/meeting admin.
Yes, i agree with you @adam, it would be cool if dapps can set up whisper node on their servers, but on the other hand this api is supposed to be used mostly by dapps and for “service” messages, but users will use nodes, so this api can help us to make status more interested for dapps and should not significantly affect decentralization