Merge pull request #19 from status-im/features/address-feedback

Address some of the feedback

x6.md

@@ -143,10 +143,10 @@ Every client initially generates some key material which is stored locally:
 
 TODO: Formatting is off here, not sure what this is supposed to be in Markdown. Assumes LaTeX?
 
+A `contact-code` is a protobuf `Bundle` message, encoded in `JSON` and converted to their `base64` string representation.
+
 Prekey bundles are exchanged through QR codes, contact codes, 1:1 or public chat messages. *We will be updating this document with information about bundle exchange through [ENS](https://ens.domains/) and [Swarm](https://swarm-guide.readthedocs.io/en/latest/introduction.html) as work progresses and technologies become more usable.*
 
-TODO: 'contact code' is not defined.
-TODO: How do you know if you run out of prekeys? What happens?
 TODO: See below on bundle retrieval, this seems like enhancement and parameter for recommendation
 
 ### 2.3. Bundle retrieval
@@ -308,8 +308,6 @@ A peer is identified by two pieces of data:
 1) An `installation-id` which is generated upon creating a new account in the `Status` application
 2) Their identity whisper key
 
-TODO: What does this mean for account recovery? Wouldn't installation id be new then too? Is this the same as Device ID in Sesame?
-
 ## 3.1 Initializiation
 
 A new session is initialized once a successful X3DH exchange has taken place.
@@ -325,8 +323,6 @@ On receiving a bundle from a given peer with a higher version, the old bundle sh
 
 ## 4. Multi-device support
 
-TODO: Not clear to me exactly how it differs from Sesame. The central place is fair, but it's also described as a 'server function', so elaborating on difference would be useful. How do they (or not) deal with account recovery btw? This seems like we might be doing different trade-offs (?)
-
 Multi-device support is quite challenging as we don't have a central place where information on which and how many devices (identified by their respective `installation-id`) belongs to a whisper-identity.
 
 Furthermore we always need to take account recovery in consideration, where the whole device is wiped clean and all the information about any previous sessions is lost.
@@ -335,11 +331,11 @@ Taking these considerations into account, the way multi-device information is pr
 
 This mean that every time a new device is paired, the bundle needs to be updated and propagated with the new information, and the burden is put on the user to make sure the pairing is successful.
 
+The method is loosely based on https://signal.org/docs/specifications/sesame/ .
+
 ## 4.1 Pairing
 
-When a user adds a new account, a new `installation-id` will be generated. The device should be paired as soon as possible if other devices are present. Once paired the contacts will be notified of the new device and it will be included in further communications.
-
-TODO: What do we mean by 'account' exactly?
+When a user adds a new account in the `Status` application, a new `installation-id` will be generated. The device should be paired as soon as possible if other devices are present. Once paired the contacts will be notified of the new device and it will be included in further communications.
 
 Any time a bundle from your $IK$ but different `installation-id` is received, the device will be shown to the user and will have to be manually approved, to a maximum of 3. Once that is done any message sent by one device will also be sent to any other enabled device.
 
@@ -349,16 +345,12 @@ The bundle will be propagated to contacts through the usual channels.
 
 Removal of paired devices is a manual step that needs to be applied on each device, and consist simply in disabling the device, at which point pairing information will not be propagated anymore.
 
-TODO: What happens if a device is offline for a long time with prekeys?
-
 ## 4.2 Sending messages to a paired group
 
 When sending a message, the peer will send a message to any `installation-id` that they have seen, using pairwise encryption, including their own devices.
 
 The number of devices is capped to 3, ordered by last activity.
 
-TODO: So this is different from the active-inactive abstraction in Sesame? What does it mean for pairwise encryption to be used for each device? Is there a different symmetric key for each device? How does that change the state in the ratched work? Are they separate sessions?
-
 ## 4.3 Account recovery
 
 Account recovery is no different from adding a new device, and it is handled in exactly the same way.
@@ -429,6 +421,7 @@ TODO: description here
 - Yes.
 - Assuming a user validates (TODO: Check this assumption) every message they are able to decrypt and validates its signature from the sender, then it is not able to be altered in transit.
     * [igorm] i'm really not sure about it, Whisper provides a signature, but I'm not sure we check it anywhere (simple grepping didn't give anything)
+    * [andrea] Whisper checks the signature and a public key is derived from it, we check the public key is a meaningful public key. The pk itself is not in the content of the message for public chats/1-to-1 so potentially you could send a message from a random account without having access to the private key, but that would not be much of a deal, as you might just as easilly create a random account)
 
 #### Authentication (YES)
 >  Each participant in the conversation receives proof of possession of a known long-term secret from all other participants that they believe to be participating in the conversation. In addition, each participant is able to verify that a message was sent from the claimed source