If you're literally just doing a front end to Matrix, I get why you have to use the current Matrix protocol. But if you're doing something that isn't Matrix, you should avoid Olm.
If you're literally just doing a front end to Matrix, I get why you have to use the current Matrix protocol. But if you're doing something that isn't Matrix, you should avoid Olm.
The thing with MLS is that it basically requires a central server for ordering the commits. For Matrix' interpretation of federation, this doesn't really work because a group isn't really owned by a server, it is a DAG of events, which, as is the nature of DAGs, does not have the total order needed for MLS commit ordering.
So either you introduce a central party that does ordering, or you do BFT-style consensus, or you try to get some idea of branching an merging of group states into MLS, which isn't really possible with what RFC 9420 offers.
My impression also is that the Matrix community really loves their DAGs and the group state management that they built, and from an MLS perspective it makes more sense to store that in the group context (either as extensions or as components as defined in draft-ietf-mls-extensions-10).
There is draft-xue-mls-decentralized which proposes two ways to MLS offer some foundations, one of which (IMO) only solves half the problem and the other (IMO) doesn't make sense.
The fediverse folks are also trying to solve this and it just is hard. https://github.com/swicg/activitypub-e2ee/issues/56
Edit: (I work on OpenMLS)
* In the current Matrix implementation, server tells the clients what the group membership is, so a server could spoof an invite to add a malicious user to a room and you'd have to rely on social mechanisms to spot it.
* There's no way to force everyone to rotate the sender key at the same time.
* On the plus side, it decentralises relatively well.
The concrete disadvantages of MLS are:
* Vanilla MLS needs a centralised sequencing function for changing group membership.
* The key bundles are much larger.
* On the plus side, only clients within the group can add new users/devices, and everyone in a given epoch shares the same group secret, so when someone rotates everyone has to rotate to participate in the new epoch.
Now, the server-controlled membership problem can be solved with Olm/Megolm if you instead have the client control the membership, using Matrix itself to define which users are authorised to be in the room, by running the Matrix DAG merge resolution on the client as well as the server. I did this a few weeks ago (in prep for The Matrix Conference next week) to show viability; it works, and has the advantage that you don't have to blow up the whole crypto implementation.
On the other hand, MLS can also be made to decentralise. DiMLS (draft-xue-mls-decentralized) isn't the only option here; DeMLS is the one we've been working with (using the Phoenix DeMLS OpenMLS fork) on the Matrix side - and works by letting MLS epochs fork and then merge again later, using puncturable functions to avoid undermining forward secrecy. This is a much bigger change; we experimented with it a few months back; details here: https://www.youtube.com/watch?v=jc7yfec3iIQ. It's promising, it works, but is much more complex and experimental.
So, TL;DR: it's possible to use olm/megolm securely (even if it's had a mixed record); I doubt strafe is doing fancy client-controlled group membership though. Separately, MLS can be used too, but it is way more complex and has its own complications. On the Matrix side we're still pursuing both (and finally making some progress, although it's a very slow burn).
I mean, if you take that out, what's left of Matrix and its differentiating proposition?