EphemeralMessages

The session ID + session counter are stored in the encrypted data.

The benefit of this design is that the id as well as the counter are not exposed to any MITM (man-in-the-middle) attacker nor the server.

To make this design work it's important that the sessionId is stored per client and not in one denormalized store per sessionId. Otherwise one client could increase the counter of another making their session basically invalid.

Process

• initialize -> proof and ask for proof
• validate proof -> respond with a proof
• validate proof
• message

Handling of missing messages and retry strategies

TODO

Usecases

• missing a update (e.g. update comes in not in order) -> the solution: have an incoming queue -> challenge: when to abort it
• getting a snapshot that doesn't apply to a known one -> precondition: what if it is an old snapshot? -> the solution: reconnect and ask the server for a new version of the document

Incoming queue

{
  [snaphotId]: {
    lastUpdatesPerAuthor: {
      [authorId]: {
        lastUpdate,
        updatesReceived
      }
    },
  }
}