Adding more background, Soatok previously looked at libolm (the library specifying the peer to peer racket cryptography) and Megolm (the specification of the group racket cryptography). And the takeaway back in 2024 was that:
The people that developed Olm and Megolm has not proven themselves ready to build a Signal competitor. In [sic] balance, most teams are not qualified to do so.
And back then in 2024:
3 of the 16 clients surveyed use the new vodozemac library. 10 still use libolm, and 3 don’t appear to implement end-to-end encryption at all.
Deprecation policies are a beautiful lie. The impact of a vulnerability in Olm or Megolm is still far-reaching, and should be taken seriously by the Matrix community.
So the fact that a key confusion vulnerability exists in the latest Megolm specification -- nevermind whether it's actually translates to a vuln in the main Element client's vodozemac Rust implementation -- is damning and reiterates Soatok's earlier takeaway.
I want Matrix to succeed, to add to the list of reliable E2EE software that currently has just one real entrant (Signal). But project management is failing Matrix right now, and it's showing through these sorts of technical mishaps. The demand and will to develop a bona fide, federated E2EE competitor is there, but the actual implementation is not.
And it's not clear that things will get better anytime soon. The timeline matters, because a number of people genuinely cannot use Signal and need an alternative. But Matrix either isn't it, or it's failing to deliver on the federation aspect that was meant to be its distinguishing strength. This is a Matrix problem at large, not just a problem for Element interoperability, and not just a problem for older non-Element clients. The Matrix project owns the spec and they alone need to do something about it from the top.
As a counterpoint (but one which admittedly doesn't include the complexity of cryptography), ActivityPub is a protocol specification that laid down the ground rules and many compatible software stacks implement it with fairly good interoperability. You reading this very post proves that point. If there was, say, a flaw in moderation capability using the protocol, it wouldn't make sense to blame the Lemmy client, or kbin software, or the default Android Mastodon client. No, the responsibility has to befall the protocol itself, because it affects everyone, even if some instances aren't yet impacted.
1 Comments
litchralee@sh.itjust.works · 2 pts · 3d
Adding more background, Soatok previously looked at libolm (the library specifying the peer to peer racket cryptography) and Megolm (the specification of the group racket cryptography). And the takeaway back in 2024 was that:
And back then in 2024:
So the fact that a key confusion vulnerability exists in the latest Megolm specification -- nevermind whether it's actually translates to a vuln in the main Element client's vodozemac Rust implementation -- is damning and reiterates Soatok's earlier takeaway.
I want Matrix to succeed, to add to the list of reliable E2EE software that currently has just one real entrant (Signal). But project management is failing Matrix right now, and it's showing through these sorts of technical mishaps. The demand and will to develop a bona fide, federated E2EE competitor is there, but the actual implementation is not.
And it's not clear that things will get better anytime soon. The timeline matters, because a number of people genuinely cannot use Signal and need an alternative. But Matrix either isn't it, or it's failing to deliver on the federation aspect that was meant to be its distinguishing strength. This is a Matrix problem at large, not just a problem for Element interoperability, and not just a problem for older non-Element clients. The Matrix project owns the spec and they alone need to do something about it from the top.
As a counterpoint (but one which admittedly doesn't include the complexity of cryptography), ActivityPub is a protocol specification that laid down the ground rules and many compatible software stacks implement it with fairly good interoperability. You reading this very post proves that point. If there was, say, a flaw in moderation capability using the protocol, it wouldn't make sense to blame the Lemmy client, or kbin software, or the default Android Mastodon client. No, the responsibility has to befall the protocol itself, because it affects everyone, even if some instances aren't yet impacted.