it doesn't have things that are required for a proper "enterprise" messaging. so you need to hack around it. multi-device users were fun. chats with no active users that somebody joins to - more fun. state synchronization between multiple servers that host same chat - very exciting. during all those exercises you start to take little by little from mls. so even while it's preserved in the core, stuff that is added around, makes it "less".to be fair, i wasn't the one that was doing implementation, i was only reviewing it. it was done by in-house crypto team. so maybe something was lost between rfc to implementation to explanations to me about how it works/supposed to work. yet, mls function is secrecy and not enterprises.
walterbell|2 years ago
MLS needs to support diverse, competing messaging systems, it's not a messaging system.
Related work, https://datatracker.ietf.org/group/mimi/about/
> Modern messaging services commonly support numerous features including plain and rich text, delivery notifications, read receipts, replies, reactions, presence, and many more. The working group will identify an extensible baseline set of messaging features and specify a content format to allow this feature set to be implemented interoperably. This format must be usable in the presence of E2EE.
simplyaccont|2 years ago
Interoperability between different messaging system (is this what mimi is about ?) it's nice, but from perspective of enterprises it's not a must (for example ms lync or skype supported xmpp federation, but i never saw it enabled.). Because of security in various aspects. For example trust between servers of different organizations. Allowing accessing "some" external users "some" internal chats. Possibility of information leaking through those chats or in case that whatever access rules for external users were incorrectly defined.
So yes, MLS/MIMI could be nice for instant messaging, but it seems not too suitable for enterprise messaging.