Gregory's Server"but e-mail !1!!!" Is probably still a number one objection from experts and power users who refuse to fathom that e-mail protocols are a viable option for instant messaging even if it demonstrably works, is fast and secure :) We'd be happy if someone engaged in a proper comparison with xmpp and matrix specs and impls, really the only three messenging protocols deployed and implemented at scale. (Can't compare that with Signal or WhatsApp which don't have wire specs!). https://github.com/deltachat/deltachat-core-rust/blob/main/standards.md
 14 comments
@besendorf @delta which under the thread model "key gets leaked" is mostly irrelevant if you don't regularly delete your messages, because if your key gets leaked, it's likely that your device was compromised and the attacker can also read your stored messages (both incoming and outgoing). Signal offers "disappearing messages", but not many people use it and many other chat apps don't offer similar features.  @ben @crepererum @besendorf even if PFS would become part of delta chat e2ee (it is for transport encryption already) it's just one concern out of many and the "but email!" folks would pull out a new obstacle likely :) Besides, @ben @delta @crepererum @besendorf > PFS has serious implementation/complexity and multi-device usability repercussions so for now it's not a focus. as a technical (sysadminish) end user, this is my main feeling about the tradeoff of PFS and why i support delta not having it. signal succeeds with walled environment. I came to delta from snikket, where PFS is enabled but when it fails, group chats break. troubleshooting isn't feasible because all errors are client side, so its a showstopper @stillgreenmoss @ben @delta @besendorf FWIW both "group chats + FS" and "open protocol" are now solved by MLS ( https://datatracker.ietf.org/doc/html/rfc9420 ). I think the issue of most chat-oriented protocols is that they don't map to "email" very well, since emails are basically "fire and forget", so key exchanges are harder/slower. @crepererum @ben @delta @besendorf this is super interesting. I didn't know about this RFC or effort. Wikipedia entry suggests it's not in use in any end user applications yet, do you know if that's true? @stillgreenmoss @ben @delta @besendorf The RFC was rather recent and I'm not aware of any end-user apps at this point. @crepererum @stillgreenmoss @ben @besendorf OpenMLS is an almost decade- long effort with the IETF work starting in 2018. We have studied it and are following developments but one known big issue is its dependency on "total message ordering" which can not be easily obtained in federated settings. Several people, including Matrix folks, have tried to remedy it but we do not know of any practical solution to make OpenMLS work reasonably well for non-centralised settings. @delta @stillgreenmoss @ben @besendorf I wonder what @raphaelrobert 's PoV is here. Are there plans to lift "total message ordering" requirement? @crepererum @delta @stillgreenmoss @ben @besendorf I can say that MLS works well in a federated environment. Federation has always been part of the picture during the design phase. The fact it doesn’t work in Matrix yet is a Matrix problem, not an MLS problem. MLS is part of the (newish) federated MIMI spec and it also works in our stack. Of course it’s still early days for MLS, but it’s already deployed by e.g. Cisco Webex.  @delta The fact that it's "just e-mail" is what makes it so wonderful and why it has saved my ass while all other means of IM are actively blocked where I live. So keep going! |
What would you like to see compared ? Overhead ? Time of implementation ? Resource usage ?