Updated Whisper Push Notifications (markdown)

Whisper-Push-Notifications.md

@@ -21,13 +21,29 @@ The crux here is how to allow `DeviceB` to trigger notifications on `DeviceA`, a
   - once decrypted, wnode will go over list of device ids (that were previously registered with given Chat SymKey) and send  notifications requests to FCM on behalf of them to them (only 1 request for one-on-one chats, `n-1` requests for group of `n` chats - that's we do not notify ourselves)
 - So, messages are never exposed, and they are routed in parallel. Notifications are also encrypted (by Chat SymKey), so are not exposed to eavesdropper. This means we are not compromising on darkness. What gets exposed, however? Well, by registering device id's with a given chat session we expose it to `wnode`.
 
+# Communication Protocol
 
-# Discovery
+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.
+
+```javascript
+var keyname = 'NOTIFICATION_PROTOCOL_KEY';
+var keypass = 'asdfasdf';
+// make sure that notification protocol key exists in whisper
+if (!web3.shh.hasSymKey(keyname)) {
+    console.log("protocol key not found, adding..");
+    web3.shh.addSymKey(keyname, web3.fromAscii(keypass));
+}
+```
+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)
+
+# Discovery and obtaining Subscription Key
 
 Original workflow for discovery mechanism was introduced in:
 
 [![image](https://cloud.githubusercontent.com/assets/188194/24608168/19317cdc-187e-11e7-995e-2adadc17a91c.png)](https://cloud.githubusercontent.com/assets/188194/24608168/19317cdc-187e-11e7-995e-2adadc17a91c.png)
 
+Let's give a concrete code example:
+
 # Sharing the key
 
 # One-to-One Chats