Having read the overviews of SimpleX's message queue and chat protocols, I feel that the project would be accurately characterised as well meaning, yet also needlessly reinventing existing technology in some places. I would like to offer my initial impressions and feedback here.
The base message queue protocol chooses sensible cryptography, but leaves some important security aspects under-specified. This can lead to mistakes when implementers do not fully understand the security implications. In the context of an open ecosystem, being under-specified here also opens up more risk of implementers causing vendor lock-in (deliberately or otherwise) by breaking interoperability.
For instance, "servers have long-lived, self-signed, offline certificates whose hash is pre-shared with clients over secure channels". Exactly how that pre-sharing is performed is left unprescribed, although SimpleX proposes that clients could introduce other clients to new servers' addresses and public keys. Key distribution is always a challenging problem in cryptography, but traditional x509 PKI is not generally considered to be an issue, so I do not understand what additional benefit to privacy would be found when distributing the keys using the SimpleX protocol itself.
The overview goes on to explain how all client-server communication takes place using blocks of data fixed at 16KiB to make it more difficult for passive observers like ISPs to collude and work out which two parties are communicating. This protection is just taking advantage of statistics - the larger a block is, the more possible messages it could contain, and so the sender is more ambiguous. The downside, though, is that it's very wasteful: assuming that you need to refresh at least once per second for a text chat to feel responsive, that would entail sending a minimum of just under 1MiB of data each way every minute, which is approaching the bandwidth required for a two-way VoIP call! Such an extreme level of resistance against active attempts at monitoring is not usually required by most people, so it would seem more sensible to me to merely ensure that SimpleX is compatible with a lower-level private protocol like TOR for when that protection is necessary.
Moving on to the overview of the chat part of the protocol, I see a fairly uninteresting JSON-based format. There is nothing immediately wrong about it, but it's hardly state-of-the-art either: there's no CBOR to reduce overhead, no JSON-LD to improve extensibility, no MIME types to account for different types of attachment.
From a long-term community perspective, the seemingly arbitrary choice of sub-protocols within the chat protocol (currently group chats, file sharing, contacts and WebRTC calls) makes me hope that SimpleX have a plan in place to avoid what has happened to Matrix. Matrix has numerous built-in features (some of which are in a rather half-baked state), often with a tight coupling between the protocol and the expected user interface for the features, making Matrix notoriously difficult to implement.
Ultimately, I fully support what SimpleX is trying to do: remove the dependence on long-term, globally-unique user IDs in internet communication, which at the moment hampers even federated applications like those that use ActivityPub or Matrix. However, I get the sense from reading the introductory documents that those behind SimpleX aren't aware of (or worse, don't care about) existing standards upon which they could build, and so the novel features are obscured by a lot of rather pedestrian protocol definition that has to be implemented. I fear that SimpleX won't be able to achieve mainstream success unless it fits better into an existing ecosystem of protocols, and whilst I wish them good luck, I must admit that I'd be putting my money on W3C's Decentralized Identifiers (DIDs) to liberate us from centrally-managed online identities.
Do you have examples of protocols that have JSON-LD extensibility mechanism that is embraced by the developer ecosystem to create interoperable extensions. I.e. where the mechanism works more than in theory. I know ActivityPub where JSON-LD is actively shunned, because devs hate it. And Solid project where the specs around using it appropriately get ever more complex. Heard that DID/VC has another extension mechanism fleshed out, but don't know about uptake.
> but leaves some important security aspects under-specified
Not sure what you mean by underspecified - it is specified to the level of wire encodings. Possibly you looked at the wrong doc?
> There is nothing immediately wrong about it, but it's hardly state-of-the-art either: there's no CBOR to reduce overhead, no JSON-LD to improve extensibility, no MIME types to account for different types of attachment.
We considered all that, and it seems that they all offer a bad value, compared with lower ubiquity. Also given that messages are padded to fixed 16kb size, there is no value in reducing JSON overhead, and files are sent as binary anyway. Being boring where it doesn't matter is good.
> avoid what has happened to Matrix
Messaging clients are hard to implement indeed, and forking the UI is usually easier than rebuilding it. We purposefully don't want to encourage the development of alternative clients too early, before the spec stabilised, to avoid the fragmentation that happened both with XMPP and with Matrix.
> to avoid the fragmentation that happened both with XMPP and with Matrix.
what fragmentation are you thinking of with Matrix? to my knowledge, we have zero fragmentation so far. some clients implement more features than others, but we don’t have any classic “my client sends different reactions to yours” or “my client archives messages differently” or “my encryption is incompatible” style problems. otherwise this smells a bit FUDy…
> we have zero fragmentation so far. some clients implement more features than others
The Matrix spec has many versions and many features. Clients implement and keep up with varying parts of it due to varying reasons usually involving varying amounts of manpower and funding. Same as with XMPP. I don't see the difference.
The difference is that Matrix is curated as a single spec (currently at v1.7: https://matrix.org/blog/2023/05/25/matrix-v-1-7-release/), which ensures that competing implementations for new features don’t fragment incompatibly but only a single one-true-way to talk a given feature exists. Anything else is a transient experiment. Meanwhile, we’ve never yet broken backwards compatibility in the spec, meaning that in theory any client can talk to any other client as long as it has implemented the required features. The inspiration here is HTML5 (albeit with versioned releases, and a clearer spec proposal process).
In other words, I’m defining fragmentation to be incompatible features - not just clients/servers which haven’t yet implemented a given feature (which is inevitable, just like browsers lag behind specced HTML and CSS features)
One way of putting this is that we’ve traded off the risk of fragmentation (but with free-for-all governance) for the risk of more centralised governance by the Matrix.org Foundation, with associated high drama when folks don’t agree with the curation decisions we make in what gets merged into the official spec.
Both are valid approaches with different tradeoffs; I was just trying to flag the confusion upthread accusing Matrix of being fragmented when it really isn’t (to a fault!)
> Matrix has numerous built-in features (some of which are in a rather half-baked state), often with a tight coupling between the protocol and the expected user interface for the features, making Matrix notoriously difficult to implement.
citation needed? If anything Matrix doesn’t have enough coupling between the API and the expected UI for features - making UIs trivial to implement (which is why there are so many unfragmented Matrix clients - in fact, I’m not aware of any fragmentation?), but the lack of UI coupling then makes performance harder.
So ironically on the Matrix side we’ve been busy adding tighter APIs like Sliding Sync (MSC3575) which make more opinionated choices about the UI in exchange for better-than-telegram perf.
The base message queue protocol chooses sensible cryptography, but leaves some important security aspects under-specified. This can lead to mistakes when implementers do not fully understand the security implications. In the context of an open ecosystem, being under-specified here also opens up more risk of implementers causing vendor lock-in (deliberately or otherwise) by breaking interoperability.
For instance, "servers have long-lived, self-signed, offline certificates whose hash is pre-shared with clients over secure channels". Exactly how that pre-sharing is performed is left unprescribed, although SimpleX proposes that clients could introduce other clients to new servers' addresses and public keys. Key distribution is always a challenging problem in cryptography, but traditional x509 PKI is not generally considered to be an issue, so I do not understand what additional benefit to privacy would be found when distributing the keys using the SimpleX protocol itself.
The overview goes on to explain how all client-server communication takes place using blocks of data fixed at 16KiB to make it more difficult for passive observers like ISPs to collude and work out which two parties are communicating. This protection is just taking advantage of statistics - the larger a block is, the more possible messages it could contain, and so the sender is more ambiguous. The downside, though, is that it's very wasteful: assuming that you need to refresh at least once per second for a text chat to feel responsive, that would entail sending a minimum of just under 1MiB of data each way every minute, which is approaching the bandwidth required for a two-way VoIP call! Such an extreme level of resistance against active attempts at monitoring is not usually required by most people, so it would seem more sensible to me to merely ensure that SimpleX is compatible with a lower-level private protocol like TOR for when that protection is necessary.
Moving on to the overview of the chat part of the protocol, I see a fairly uninteresting JSON-based format. There is nothing immediately wrong about it, but it's hardly state-of-the-art either: there's no CBOR to reduce overhead, no JSON-LD to improve extensibility, no MIME types to account for different types of attachment.
From a long-term community perspective, the seemingly arbitrary choice of sub-protocols within the chat protocol (currently group chats, file sharing, contacts and WebRTC calls) makes me hope that SimpleX have a plan in place to avoid what has happened to Matrix. Matrix has numerous built-in features (some of which are in a rather half-baked state), often with a tight coupling between the protocol and the expected user interface for the features, making Matrix notoriously difficult to implement.
Ultimately, I fully support what SimpleX is trying to do: remove the dependence on long-term, globally-unique user IDs in internet communication, which at the moment hampers even federated applications like those that use ActivityPub or Matrix. However, I get the sense from reading the introductory documents that those behind SimpleX aren't aware of (or worse, don't care about) existing standards upon which they could build, and so the novel features are obscured by a lot of rather pedestrian protocol definition that has to be implemented. I fear that SimpleX won't be able to achieve mainstream success unless it fits better into an existing ecosystem of protocols, and whilst I wish them good luck, I must admit that I'd be putting my money on W3C's Decentralized Identifiers (DIDs) to liberate us from centrally-managed online identities.