matrix-js-sdk

I'd quite like some more high level documentation for the Matrix JS SDK (https://github.com/matrix-org/matrix-js-sdk). I've been looking at it for quite some time and still don't understand how timelines work. Would bw fascinating if your tool could bring something useful to light.

No, it's just been a painful problem to solve. If you're interested, you can see the massive discussion around it at https://github.com/matrix-org/matrix-spec-proposals/pull/228.... The implementations have been around for a while, and as it happens we got to consensus on the spec discussion yesterday, and the PRs to enable it by default in Element Web and Synapse landed an hour ago: https://github.com/matrix-org/matrix-js-sdk/pull/2524 https://github.com/vector-im/element-web/pull/22242 https://github.com/matrix-org/synapse/pull/13273

Currently we don't force TURN, so in practice this means that voice packets go direct between the clients if possible, and so the IP addresses of the clients are necessarily exposed to each other. However, this is utterly trivial to fix: matrix-js-sdk already exposes https://github.com/matrix-org/matrix-js-sdk/blob/96ba061732b... and we simply haven't exposed it as a setting in Element Call yet. I've filed a bug for it at https://github.com/vector-im/element-call/issues/251 - thanks for bringing it up! In terms of moderation: this is no different to moderation in Matrix as a whole, where we're already busy working on shared greylists (MSC2313 and friends) - https://matrix.org/blog/2020/10/19/combating-abuse-in-matrix... has more details at the end.

The media quality that you hear is entirely up to the sender's WebRTC implementation. If you're calling another Element Call user, we currently use the default audio constraints when capturing audio: https://github.com/matrix-org/matrix-js-sdk/blob/96ba061732b... - but if you wanted stereo, you could put { channelCount: 2, sampleRate: 48000 } or whatever into that line to achieve it. I'll file a bug to make this configurable. EDIT: https://github.com/vector-im/element-call/issues/249

So in the initial beta we haven't turned on E2EE, purely because it will make it way harder to debug any problems which surface. However, at this rate, things are looking pretty stable and i'd expect us to enable it in the next few weeks. It uses normal Matrix E2EE, which means a Double Ratchet between the pairs of devices participating in a given conversation, which is then used to secure the signalling which is used to set up the calls between the devices. The call media is transport-layer encrypted via DTLS and SRTP, so as long as the signalling with the DTLS fingerprints is secured by Matrix E2EE, the whole call fabric will be E2EE. https://github.com/matrix-org/matrix-js-sdk/pull/2002 is the PR we actually need to merge in order to enable E2EE on it, ftr.

I figured it out -- the problem is that you cannot change the encryption parameters for a room, as any new m.room.encryption events are explicitly ignored[1]. I set up a new room and sent a custom state event and it worked. There is obviously a reason why you can't disable encryption once enabled, but it does suck that fields within m.room.encryption which are entirely advisory (since as far as I know the current implementation doesn't block messages that use old sessions) can't be changed. It's good to see that the session is being rolled somewhat frequently though. This does explain some of my questions about why the old-school key backups kept getting larger even though I haven't joined any new chats. [1]: https://github.com/matrix-org/matrix-js-sdk/blob/03a54353be9...

Hm, it should work, at least on matrix-js-sdk, based on a quick look at https://github.com/matrix-org/matrix-js-sdk/blob/907cf19f054.... However, you're right that the UI isn't exposed in Riot currently, and the code may have bitrotted; looks like there isn't an explicit test for it.

So, this was a design flaw in how matrix-js-sdk was originally implemented - it simply didn't cache any state whatsoever locally, so every new launch meant re-syncing the whole world to the client. This can obviously be improved by lazyloading, but for now we've fixed it by caching full offline state in indexeddb - https://github.com/matrix-org/matrix-js-sdk/pull/363 & friends. This speeds up launch time to a few seconds, if that - and as we go through doing more lazyloading it'll be even better. We also need to make the app progressively loaded in general rather than a big ball of webpack. Coincidentally, the new version of Riot which uses the new indexeddb backend should be going live tomorrow (live today on riot.im/staging).