`Room` and `Crypto` currently have some tight coupling in the form of a call to
`trackRoomDevices` when out-of-band members are loaded. We can improve this by
instead having Crypto listen out for a `RoomSateEvent.Update` notification.
We didn't close streams in group calls (presumably from back when
we used the same stream for all calls rather than cloning?) but this
left stray screenshare streams in the mediahandler when a participant
left whilst we were screensharing.
Fixes https://github.com/vector-im/element-call/issues/742
This PR introduces MatrixClient.initRustCrypto, which is similar to initCrypto, except that it will use the Rust crypto SDK instead of the old libolm-based implementation.
This is very much not something you want to use in production code right now, because the integration with the rust sdk is extremely skeletal and almost everything crypto-related will raise an exception rather than doing anything useful.
It is, however, enough to demonstrate the loading of the wasmified rust sdk in element web, and a react sdk with light modifications can successfully log in and out.
Part of vector-im/element-web#21972.
* add deleteAccountData endpoint
* check server support and test
* test current state of memorystore
* interpret account data events with empty content as deleted
* add handling for (future) stable version of endpoint
* add getSafeUserId
* user getSafeUserId in deleteAccountData
* better jsdoc for throws documentation
Part of https://github.com/vector-im/element-web/issues/21972. Eventually I want to replace the whole of the current `Crypto` implementation with an alternative implementation, but in order to get from here to there, I'm factoring out a common interface which will be implemented by both implementations.
I'm also determined to fix the problem where the innards of the crypto implementation are exposed to applications via the `MatrixClient.crypto` property.
It's not (yet) entirely clear what shape this interface should be, so I'm going with a minimal approach and adding things as we know we need them. This means that we need to keep the old `client.crypto` property around as well as a new `client.cryptoBackend` property. Eventually `client.crypto` will go away, but that will be a breaking change in the js-sdk.
* Fix issue where the root event of a thread had to be loaded in a complicated way
* Fix issue where edits to the last event of a thread would get lost
* Fix issue where thread reply count would desync
* Refactor relations pagination mocking for tests
A call to ensureSession() has two steps:
1. prepareSession(), where an outbound group session might get created
or rotated
2. shareSession(), where an outbound group session might get
encrypted and queued up to be sent to other devices
Both of those calls may mostly fail due to storage errors, yet only the
errors from prepareSession get propagated to the caller.
Errors from prepareSession will mean that you can't get an
outbound group session so you can't encrypt an event.
Errors from shareSession, especially if the error happens in the part
where the to-device requests are queued up to be sent out, mean that
other people will not be able to decrypt the events that will get
encrypted using the outbound group session.
Both of those cases are catastrophic, the second case is just much
harder to debug, since the error happens on another device at some
arbitrary point in the future.
Let's just return the error instead, people can then retry and the
storage issue might have been resolved, or at least the error becomes
visible when it happens.
ensureOutboundSession uses and modifies the setupPromise of the
MegolmEncryption class. Some comments suggest that setupPromise will
always resolve, in other words it should never contain a promise that
will get rejected.
Other comments also seem to suggest that the return value of
ensureOutboundSession, a promise as well, may fail.
The critical error here is that the promise that gets set as
the next setupPromise, as well as the promise that ensureOutboundSession
returns, is the same promise.
It seems that the intention was for setupPromise to contain a promise
that will always resolve to either `null` or `OutboundSessionInfo`.
We can see that a couple of lines before we set setupPromise to its new
value we construct a promise that logs and discards errors using the
`Promise.catch()` method.
The `Promise.catch()` method does not mutate the promise, instead it
returns a new promise. The intention of the original author might have
been to set the next setupPromise to the promise which `Promise.catch()`
produces.
This patch modifies the updating of setupPromise in the
ensureOutboundSession so that setupPromise discards errors correctly.
Using `>>=` to represent the promise chaining operation, setupPromise is
now updated using the following logic:
setupPromise = previousSetupPromise >>= setup >>= discardErrors
Rather than waiting for the application to call `.startClient`, upload the
device keys during `initCrypto()`. Element-R is going to approach this slightly
differently (it wants to manage the decision on key uploads itself), so this
lays some groundwork by collecting the libolm-specific bits together.
To make it easier to track down where to-device messages are getting lost,
add a custom property to each one, and log its value. Synapse will also log
this property.
* bugfix: sliding sync initial room timelines shouldn't notify
Flag timeline events as `fromCache` when `initial: true` rooms
are received. This stops notifications appearing inappropriately
when you scroll the room list or spider the room list, as it
causes `liveEvent=false`.
* Use num_live to detect liveness; with jest test
* Linting
* jsdoc
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
If the client uses a widget to join group calls, like Element Web does, then the local device could be joined to the call without GroupCall knowing. This adds a field to GroupCall that allows the client to tell GroupCall when it's using another session to join the call.
vector-im/element-web#23819 is an intermittent failure to correctly initiate a user verification process. The
root cause is as follows:
* In matrix-react-sdk, ensureDMExists tries to create an encrypted DM room, and assumes it is ready for use
(including sending encrypted events) as soon as it receives a RoomStateEvent.NewMember notification
indicating that the other user has been invited or joined.
* However, in sync.ts, we process the membership events in a /sync response (including emitting
RoomStateEvent.NewMember notifications), which is long before we process any m.room.encryption event.
* The upshot is that we can end up trying to send an encrypted event in the new room before processing
the m.room.encryption event, which causes the crypto layer to blow up with an error of "Room was
previously configured to use encryption, but is no longer".
Strictly speaking, ensureDMExists probably ought to be listening for ClientEvent.Room as well as RoomStateEvent.NewMember; but that doesn't help us, because ClientEvent.Room is also emitted
before we process the crypto event.
So, we need to process the crypto event before we start emitting these other events; but a corollary of that
is that we need to do so before we store the new room in the client's store. That makes things tricky, because
currently the crypto layer expects the room to have been stored in the client first.
So... we have to rearrange everything to pass the newly-created Room object into the crypto layer, rather than
just the room id, so that it doesn't need to rely on getting the Room from the client's store.
Travis Ralston