From 4ac2c359e05ad6bb22c659149803eb5ef51f648c Mon Sep 17 00:00:00 2001 From: Victor Farazdagi Date: Tue, 11 Apr 2017 04:11:03 +0300 Subject: [PATCH] Updated Whisper Push Notifications (markdown) --- Whisper-Push-Notifications.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/Whisper-Push-Notifications.md b/Whisper-Push-Notifications.md index bdfffd0..b48d4a1 100644 --- a/Whisper-Push-Notifications.md +++ b/Whisper-Push-Notifications.md @@ -7,14 +7,18 @@ It is crucial to understand what is **Whisper Notification Service** is designed ## High-Level Overview of the process +[![image](https://cloud.githubusercontent.com/assets/188194/24888385/c44058bc-1e6b-11e7-93c8-9ab81718b478.png)](https://cloud.githubusercontent.com/assets/188194/24888385/c44058bc-1e6b-11e7-93c8-9ab81718b478.png) -[![image](https://cloud.githubusercontent.com/assets/188194/24887158/7abde7ee-1e62-11e7-946b-4b9cc8fdb390.png)](https://cloud.githubusercontent.com/assets/188194/24887158/7abde7ee-1e62-11e7-946b-4b9cc8fdb390.png) -The crux here is not discovery, but once discovery of capable wnode happens, and `DeviceA` has a subscription, how to allow `DeviceB` to trigger notifications, all this w/o knowing much of which wnode is used, or details of `DeviceA`. And `ChatID` solves this issue elegantly (the beauty is that it works for both one-on-one and group chats). +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 `ChatID` and `Chat SymKey` so that newcomers can add their devices to subscribers). **Important Notes:** -- It is important to understand that notification request messages go *along* the normal communication i.e. on `DeviceA` you send, say, encrypted message to `DeviceB` (so, only `DeviceB` can open envelope), at the same time you need to send a broadcast message encrypting it with **publicly known** notification protocol key (the same key used in discovery, see below). -- So, messages are never exposed, but certain information does get exposed +- 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` + - some node over there, will be able to decrypt your broadcast (the only one that has SymKey) + - once decrypted, wnode will go over list of device ids (that were previously registered with given Chat SymKey) and send to notifications to them (only to one for one-on-one chats, `n-1` notification requests on group of `n` chats - that's we do not notify ourselfves) +- So, messages are never exposed, and they are routed in parallel. Notifications are also encrypted (by Chat SymKey), so are not exposed to eavesdropper. So, we are not compromising darkness. What gets exposed? Well, by registering device id's with a given chat session we expose it to `wnode`. # Discovery