Kegan Dougal

This is a ticking time bomb. We are likely to see this as the age of client's DBs get older and more OTKs accumulate which are never claimed, consuming the...

https://github.com/element-hq/synapse/issues/17267 can cause us to have indefinitely claimed OTKs because the receiver timed out the request.

Indeed, the reason why I'm flagging it is because it outlines a real-world example of how we can accumulate keys on the client.

- A desync solution _could_ help with https://github.com/element-hq/element-meta/issues/2356 if the server included in-flight key IDs. - Re concurrency fails, there are other sources which we may end up hitting e.g...

Regarding server-rollbacks, @uhoreg had a rather simple and elegant solution: just drop the OTKs table on rollbacks. This will cause 0 OTK counts to be sent down `/sync`, causing clients...

Thinking more on this, we could also do a similar solution for clients - if the `/keys/upload` endpoint returns a HTTP 400 indicating "key already exists" -> delete all OTKs...

I've made https://github.com/matrix-org/matrix-spec-proposals/pull/4162 which I think addresses this.

We're actively working on this, despite the lack of activity on this particular issue. In particular, within the last few months we have a [dedicated test suite](https://github.com/matrix-org/complement-crypto) now to identify...

Currently this does _not_ include Element Desktop as rust crypto isn't enabled by default (yet). We expect this will change on a timescale of weeks not months. We've been discussing...

Recently I've been giving updates for this on [This Week in Matrix](https://matrix.org/blog/2024/06/14/this-week-in-matrix-2024-06-14/#dept-of-encryption-closed-lock-with-key). If you fail to decrypt a message please: - send a bug report to us and mention: -...