From 78ddd0a99e055a8878cecb2e520c64b6ebdcd576 Mon Sep 17 00:00:00 2001 From: Victor Farazdagi Date: Thu, 13 Apr 2017 08:25:41 +0300 Subject: [PATCH] Updated Whisper Push Notifications (markdown) --- Whisper-Push-Notifications.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Whisper-Push-Notifications.md b/Whisper-Push-Notifications.md index 4ba036b..e31aaba 100644 --- a/Whisper-Push-Notifications.md +++ b/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 broadcasting using Discovery Protocol SymKey. However, `statusd wnode` command (that is used to start notification-enabled wnodes) also supports using asymmetric keys to kick off the process. For further details, see examples below. +- `Device A` can start the protocol by broadcasting using Discovery Protocol SymKey. However, `statusd wnode` command (that is used to start notification-enabled wnodes) also supports using asymmetric keys to kick off the process. For further details, see examples below. - 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) - once done, you need to send a broadcast message encrypting it with `Chat SymKey`