Updated Whisper Push Notifications (markdown)

Whisper-Push-Notifications.md

@@ -14,7 +14,7 @@ It is crucial to understand what is **Whisper Notification Service** is designed
 The crux here is how to allow `DeviceB` to trigger notifications on `DeviceA`, all this w/o knowing much of which wnode is used, or details of `DeviceA`. And `Chat SymKey` solves this issue elegantly (the beauty is that it works for both one-on-one and group chats, all you need to ensure is share a secret, namely `Chat SymKey`, so that newcomers can add their devices to subscribers list).
 
 **Important Notes:**
-- `Device A` starts the protocol by sending encrypted message using Discovery Protocol PubKey (Status test cluster will have a single PubKey installed on all the nodes, allowing any of them to respond on discovery requests).
+- `Device A` starts the protocol by sending encrypted message using Discovery Protocol PubKey (Status test cluster will have a single PubKey installed on all the nodes, allowing any of them to respond to discovery requests).
 - While discovery happens using asymmetric cryptography, once you obtain `Subscription SymKey` and `Chat SymKey` you rely on symmetric encryption.
 - It is important to understand that notification request messages go *along* the normal communication i.e. 
   - on `DeviceA` you send encrypted message to `DeviceB` (so, only `DeviceB` can open envelope)
@@ -30,11 +30,11 @@ The crux here is how to allow `DeviceB` to trigger notifications on `DeviceA`, a
 
 ⭐️ ⭐️ ⭐️ The code below is **outdated** (it was written for Geth 1.5.9, and with Geth 1.6.0 Whisper API changed drastically). It is still advised to skim over the code and comments, to get better understanding of the idea. And at the end of this document, we include full-fledged test suite (to be run with [Mocha](https://mochajs.org/)).
 
-Suppose, you started service node(s) using `statusd --datadir wnode1 wnode --notify -nodekey ./wnodekey  -.shh.firebaseauth ./firebaseuathkey`, where `wnodekey` and `firebaseauthkey` files contain node's private key and FCM authorization key respectively. Now, your server is ready to receive requests encrypted with its PubKey, which for our cluster is `0x040edb0d71a3dbe928e154fcb696ffbda359b153a90efc2b46f0043ce9f5dbe55b77b9328fd841a1db5273758624afadd5b39638d4c35b36b3a96e1a586c1b4c2a`.
+Suppose you started service node(s) using `statusd --datadir wnode1 wnode --notify -nodekey ./wnodekey  -.shh.firebaseauth ./firebaseuathkey`, where `wnodekey` and `firebaseauthkey` files contain node's private key and FCM authorization key respectively. Now, your server is ready to receive requests encrypted with its PubKey, which for our cluster is `0x040edb0d71a3dbe928e154fcb696ffbda359b153a90efc2b46f0043ce9f5dbe55b77b9328fd841a1db5273758624afadd5b39638d4c35b36b3a96e1a586c1b4c2a`.
 
 On client side, we need to use protocol PubKey and pre-defined topic:
 
-```javascript
+```js
 var protocolKey = '0x040edb0d71a3dbe928e154fcb696ffbda359b153a90efc2b46f0043ce9f5dbe55b77b9328fd841a1db5273758624afadd5b39638d4c35b36b3a96e1a586c1b4c2a';
 var sendDiscoveryRequest = function (identity) {
     // notification server discovery request is a signed (sent from us),
@@ -70,7 +70,7 @@ var dropClientSessionTopic = '0x3a6656bb'; // DROP_CLIENT_SESSION
 ```
 
 Finally, in order to test everything out, you'd better use two different clients not one. So, assume that we have two nodes (`Device A` and `Device B`) which have different underlying Status daemons:
-```javascript
+```js
 var web3 = new Web3();
 web3.setProvider(new web3.providers.HttpProvider('http://localhost:8645')); // Device A
 web3.setProvider(new web3.providers.HttpProvider('http://localhost:8745')); // Device B
@@ -203,7 +203,7 @@ Now, why do we have distinct client and chat keys? The reason is simple: client
 - trigger notifications on all the other registered devices
 - all this in secure/dark way
 
-Here is how you create chat session key might look like (remember we are still using `web3` object connected to `Device A` node):
+Here is what creating chat session key might look like (remember we are still using `web3` object connected to `Device A` node):
 
 ```js
 var newChatSessionTopic = '0x509579a2'; // NEW_CHAT_SESSION
@@ -339,10 +339,10 @@ 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 "' + identity + '" not found in whisper';
+    throw 'identity "' + identity + '" not found in whisper';
 }
 
-// for for key sharing, it is up to you how you implement it (which topic to use etc)
+// for key sharing, it is up to you how you implement it (which topic to use etc)
 var filter = web3.shh.filter({
     to: identity, // wait for anon. messages to ourselves
     topics: ['chatKeySharing']
@@ -378,7 +378,7 @@ filter.watch(function (error, result) {
             + '"icon": "https://status.im/img/logo.png",'
             + '"click_action": "https://status.im"'
             + '},'
-            + '"to": "{{ ID }}"' // this get replaced by device id your've registered
+            + '"to": "{{ ID }}"' // this gets replaced by device id you've registered
             + '}',
             ttl: 20,
             keyname: keyname