MSC3884: Sliding Sync Extension: E2EE

[kegsay]

Rendered

Client Implementation
Server Implementation

[deepbluev7]

This field has to always be included, otherwise there is no way for the client to tell, if the fallback key got used.

HOWEVER:

You can actually probably solve that with the sliding sync API, by having the client explicitly tell the server about what fallback keys it wants to know about, when they are used. Then the server would have to include them everytime when they are used, but could not include them in the common case of them being unused. The same could be done for the one time keys count, where you specify a minimum number you want to have and if you have those, the server doesn't update you about it.

This is however a bit racy, as a client might be told about a used key, while it is still uploading a key. But I think that is already an issue we have today.

Basically the request parameters would then look something like this:

{
  "enabled": true,
  "minimum_device_one_time_keys_count": {
    "signed_curve25519": 50 // tell the server to notify the client, if the OTKs fall below this limit
  },
  "fallback_key_types": [ "signed_curve25519" ] // tell the server to notify the client, if no such key is present
}

[deepbluev7]

This probably requires the server to tell the client, if a key type is unsupported though.

[deepbluev7]

Related spec issue: #3298

Unsupported keys are hard to distinguish from "no change".

[kegsay]

I like this idea overall, especially with the "min" values. I'd be interested to hear if this makes things any easier on clients, or just saves a bit of bandwidth.

[deepbluev7]

What are the semantics for this? When do I get a "changed" event? Only for device lists that changed during this connection? Or does this work on the delta token? Maybe this should have its own since and next batch token? Key data is actually a LOT of data, so invalidating that on every reconnect would be pretty scary. And not being told your device list is possibly missing changed events, because the delta token expired is equally scary.

[kegsay]

The semantics are the same as sync v2 regarding getting a "changed" or "left" event.

Currently, the proxy will aggregate changed/left responses from sync v2 then deliver this to the client, only purging the arrays server-side once the client has acknowledged the response. This does mean that if you're offline for a while, these arrays can be large. This means we will always tell you of a change in a user's device lists, as this aggregation process happens outside the connection scope (it's constantly accumulated in the proxy from the moment you first start syncing until the end of time).

We don't currently have delta token support in this extension, but it might be worthwhile to add it if we can get the semantics right.

Also worth noting that in practice the size of these arrays isn't a large part of the overall sync response, even if you have been offline for a while.

[deepbluev7]

My concern is mostly, that it would be easy to get this wrong on the client side, if you don't treat all devices as changed after a reconnection, where the server doesn't send you change lists from before you reconnected. Currently clients mostly rely on getting all change events as long as they don't do a new initial sync, but with sliding sync the "initial sync" could possibly happen quite often and by accident and in that case you would need to treat ALL keys as stale. You can probably implement that correctly in a client, but some more explicit notification, that your delta token wasn't used and your whole lists should be treated as stale might be harder to get wrong.