x6: Add TODOs/questions

x6.md

@@ -141,8 +141,14 @@ Every client initially generates some key material which is stored locally:
 - A signed prekey based on secp256k1 - $SPK$;
 - A prekey signature - <i>Sig($IK$, Encode($SPK$))</i>
 
+TODO: Formatting is off here, not sure what this is supposed to be in Markdown. Assumes LaTeX?
+
 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
 
 X3DH works by having client apps create and make available a bundle of prekeys (the X3DH bundle) that can later be requested by other interlocutors when they wish to start a conversation with a given user.
@@ -155,6 +161,8 @@ In the X3DH specification, a shared server is typically used to store bundles an
 - Decentralized permanent storage (e.g. Swarm, IPFS).
 - Whisper
 
+TODO: Comment, it isn't clear what we actually _do_. It seems as if this is exploring the problem space. From a protocol point of view, it might make sense to describe the interface, and then have a recommendation section later on that specifies what we do. See e.g. Signal's specs where they specify specifics later on. 
+
 Since bundles stored in QR codes or ENS records cannot be updated to delete already used keys, the approach taken is to rotate more frequently the bundle (once every 24 hours), which will be propagated by the app through the channel available.
 
 ### 2.4. 1:1 chat contact request
@@ -163,6 +171,8 @@ There are two phases in the initial negotiation of a 1:1 chat:
 1. **Identity verification** (e.g., face-to-face contact exchange through QR code, Identicon matching). A QR code serves two purposes simultaneously - identity verification and initial bundle retrieval;
 1. **Asynchronous initial key exchange**, using X3DH.
 
+TODO: I'd consider calling the first Trust Establishment and lnik to that document
+
 #### 2.4.1. Initial key exchange flow (X3DH)
 
 The initial key exchange flow is described in [section 3 of the X3DH protocol](https://signal.org/docs/specifications/x3dh/#sending-the-initial-message), with some additional context:
@@ -298,6 +308,8 @@ 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.
@@ -313,6 +325,8 @@ 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.
@@ -325,6 +339,8 @@ This mean that every time a new device is paired, the bundle needs to be updated
 
 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?
+
 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.
 
 Once a new device is enabled, a new contact-code/bundle will be generated which will include pairing information.
@@ -333,12 +349,16 @@ 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.
@@ -354,9 +374,12 @@ The same considerations apply as in [section 4 of the X3DH spec](https://signal.
 
 **_TODO: Add any additional context here not covered in the X3DH and DR specs, e.g.:_**
 
+TODO: E.g. what?
 
 ### To be implemented
 
+TODO: Not clear what exactly is proposed as enhancement and what extra guarantees that would provide
+
 ## 1. Introduction
 
 #### 1.5.x. Contact request