Updated Whisper Push Notifications (markdown)

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
+# 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)