Updated Whisper Push Notifications (markdown)

Whisper-Push-Notifications.md

@@ -27,7 +27,11 @@ The crux here is how to allow `DeviceB` to trigger notifications on `DeviceA`, a
 
 # Communication Protocol
 
-In Whisper/5 all messages are encrypted, either with symmetric/topic key or asymmetric public key. That means, when broadcasting we need to have some SymKey that wnodes capable of Notification Services can decrypt and respond to.
+## Accessing Notification Service enabled nodes using symmetric/topic keys
+
+Suppose, you started service node(s) using `statusd --datadir wnode1 wnode --notify --password ./wnodepassword  --firebaseauth ./firebaseuathkey`. Such a server will expect certain pre-defined topic symmetrically encrypted with password (that in this example lives in file `wnodepassword`).
+
+On client side, we need to add that password as symmetric key, to be used later on for discovery requests:
 
 ```javascript
 var keyname = 'NOTIFICATION_PROTOCOL_KEY';
@@ -37,9 +41,34 @@ if (!web3.shh.hasSymKey(keyname)) {
     console.log("protocol key not found, adding..");
     web3.shh.addSymKey(keyname, web3.fromAscii(keypass));
 }
+
+var sendDiscoveryRequestUsingKeySym = function (identity) {
+    // notification server discovery request is a signed (sent from us) broadcast,
+    // encrypted with Notification Protocol Symmetric Key (which is publicly known)
+    var err = web3.shh.post({
+        from: identity,
+        topics: [discoverServerTopic],
+        ttl: 20,
+        keyname: keyname
+    });
+    if (err !== null) {
+        console.log("message NOT sent")
+    } else {
+        console.log("message sent OK")
+    }
+};
 ```
 It is important to understand that this key is publicly known (we will use different password on our cluster, you may use your own password, see `statusd wnode --password` option). So, encryption here doesn't provide privacy - instead, it allows Notification Service capable nodes to filter requests to them (as they will be able to decrypt those messages).
 
+## Accessing Notification Service enabled nodes using asymmetric key
+
+Now, `statusd` can be started with loaded identity (which is basically a private key) for asymmetric encryption, e.g. `statusd --datadir wnode1 wnode --notify --identity ./wnodekey --firebaseauth ./firebaseuathkey`. To start a discovery request:
+
+```js
+
+```
+
+
 Assume that we have two nodes (`Device A` and `Device B`) which have different underlying nodes:
 ```javascript
 var web3 = new Web3();