From a769f02a94eb7e9c8df00afbef62372fa01aa50f Mon Sep 17 00:00:00 2001
From: Victor Farazdagi <simple.square@gmail.com>
Date: Fri, 14 Apr 2017 11:18:21 +0300
Subject: [PATCH] Updated Whisper Push Notifications (markdown)

---
 Whisper-Push-Notifications.md | 36 +++++++++++++----------------------
 1 file changed, 13 insertions(+), 23 deletions(-)

diff --git a/Whisper-Push-Notifications.md b/Whisper-Push-Notifications.md
index 40c0162..8c99c2c 100644
--- a/Whisper-Push-Notifications.md
+++ b/Whisper-Push-Notifications.md
@@ -334,7 +334,7 @@ web3.setProvider(new web3.providers.HttpProvider('http://localhost:8745'));
 // pre-defined test identity (it gets injected automatically by statusd)
 var identity = '0x04eedbaafd6adf4a9233a13e7b1c3c14461fffeba2e9054b8d456ce5f6ebeafadcbf3dce3716253fbc391277fa5a086b60b283daf61fb5b1f26895f456c2f31ae3';
 if (!web3.shh.hasIdentity(identity)) {
-    throw 'idenitity "0x04eedbaafd6adf4a9233a13e7b1c3c14461fffeba2e9054b8d456ce5f6ebeafadcbf3dce3716253fbc391277fa5a086b60b283daf61fb5b1f26895f456c2f31ae3" not found in whisper';
+    throw 'idenitity "' + identity + '" not found in whisper';
 }
 
 // for for key sharing, it is up to you how you implement it (which topic to use etc)
@@ -366,7 +366,15 @@ filter.watch(function (error, result) {
         var err = web3.shh.post({
             from: identity,
             topics: [sendNotificationTopic],
-            payload: "Hello, you've got mail!!", // yes, arbitrary data!
+            payload: '{' // see https://firebase.google.com/docs/cloud-messaging/http-server-ref
+            + '"notification": {'
+            + '"title": "status.im notification",'
+            + '"body": "Hello this is test notification!",'
+            + '"icon": "https://status.im/img/logo.png",'
+            + '"click_action": "https://status.im"'
+            + '},'
+            + '"to": "{{ ID }}"' // this get replaced by device id your've registered
+            + '}',
             ttl: 20,
             keyname: keyname
         });
@@ -380,10 +388,6 @@ filter.watch(function (error, result) {
 ```
 We provide all the code for `Device B` in a single chunk. Basically, all that `Device B` does, is: wait for shared key, register device, trigger notification.
 
-# Implementation notes I: One-to-One Chats
-
-# Implementation notes II: Group Chats
-
 # Complete Sample
 
 Full sample page used for testing can be found here: https://gist.github.com/farazdagi/5ac082ddf006d00de422385f07d41ad3
@@ -392,26 +396,12 @@ In order to use that page you need to start the following:
 ```bash
 statusd --datadir app1 --http --httpport 8645 wnode # as Device A
 statusd --datadir app2 --http --httpport 8745 wnode # as Device B
-statusd --datadir wnode2 wnode --notify --password asdfasdf --injectaccounts=false --firebaseauth=XXX # as notification server, you need to setup your app with FCM and use your own authorization key
+statusd --datadir wnode1 wnode --notify --identity ./wnodekey --injectaccounts=false --firebaseauth ./firebaseauthkey
 ```
 
 If you run that page in gist, you should see sth like this:
 
 ![image](https://cloud.githubusercontent.com/assets/188194/24966636/34a226ea-1fb0-11e7-9b18-b3595ed108e6.png)
 
-# Important Questions (with answers!)
-
-### If Discovery Protocol's SymKey is publicly known, what will happen if some attacker just forks `status-go` repo, and responds to discovery request?
-
-It is crucial to understand what might be exposed:
-- clients' public keys
-- clients' device IDs
-- some extra info which you pass in notifications
-
-So, public keys exposure shouldn't be a huge problem. When it comes to device IDs, can attacker use them to send unwanted/spam notifications? Well, since those device IDs were generated for a given FCM app, they are useless to attacker unless authorization key to that app is known (and it isn't). Finally, to make sure we do not over-expose ourselves, make sure that you do not include too much of internal information in notifications - then even if attacker can get those, not much will be gained (although, we must warn users that by enabling notifications they potentially enable 3rd party to track the fact of communication - **not the content of it of course**).
-
-Now, on incentives: we must make sure that economic rewards are such that it is more interesting for 3rd party to provide proper service than to involve in malicious acts.
-
-
-
-# Limitations
\ No newline at end of file
+# Limitations
+- the main limitation of this release is the fact that all the data is in-memory, i.e. no persistent store, and once node goes down subscriptions, chats, devices - all that info is gone. This issue will be addressed with high priority (and it is actually not hard to implement)
\ No newline at end of file