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

TODO: the snapshots are stored in order - old snapshots can be cleaned out (or at least the updates)

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
      }
    },
  }
}

Behaviour

States

syncing

-> new local changes get sent as updates -> new incoming updates get applied -> if an update fails then send it again

snapshot-in-flight

-> goal: get back to syncing

-> wait for the snapshot to be confirmed

-> if it failed apply the document: try again

error

-> goal: get back to syncing

-> load the document again and try to get back to syncing (send along latest known info)