Instant Messengers Analysis and Comparison
Instant Messengers Analysis and Comparison
The table is quite big (190+ lines of hand-written HTML) and it doesn't fit on mobile phone screens unless you zoom out. It should be fine on desktop. It also specifies the criteria followed and has analysis of some of the IMs in the table (not close to all of them, I hope to add more analysis in the future).
Counter-arguments are always welcome. Sources and additional information too. Note that the typical privacy recommendation (Signal) is not recommended here. It does not meet our criteria, being centralized and requiring a phone number. I don't want to hate on Signal since it's doing a decent job spreading the importance of E2EE, however we can not recommend it for the given reasons.
Didn't expected an actual valid comparison, good work!
SimpleX rules!
18yeah, I agree. I hope the project lasts, because it's by far the best option. I hope they manage to implement having the same "account" in both desktop and mobile, it's the only feature I miss.
12
There's a million of these lists, all chosen critera's chosen carefully or outright false to fit their bias. Like why the hell is electron mentioned in a privacy comparison? XMPP is a protocol too, not a client, which makes comparison to Element make no sense, why would they not compare it to Matrix and ignore all of their other features? This list is complete shit.
11electron is mentioned in the OS supported section as a platform. Not taken into account for the privacy part, as you can see it is neither red or green. Also, there's not a single mention of Element, because it's just one client, yes.
I encourage you to read our criteria, I think you'll find it quite reasonable.
4
Another very similar resource:
8thanks, I didn't know this one
4
SimpleX being a hybrid p2p model means that it leaks more metadata to 3rd parties than XMPP for example.
They explicitly recommend using Tor with Simplex for that reason.
I would suggest you change the "meta data" field for it to "probably ok", but the design of the system makes it a risk factor, so without Tor it is probably more of a "barely ok".
6The latest specifications for OMEMO (XMPP) do some meta-data protection similar to Signal, but admittably few clients (Moxxy & Kaidan) support it so far and roll-out has been very slow.
I would suggest to change it to "bad" and write "work in progress" or so.
5oh I didn't know what changes OMEMO 2 introduced. Thanks, I'll add a note.
3
I want to like SimpleX, but (a) notifications on Android are iffy, and (b) there's no multi-device support. (A) I could live with, but (b) makes it a non-starter. I did try "make a group and add every device as a different user," but it's hard, confusing, and I simply can not ask my friends and family go through that shit just to IM. There's a ticket for multi-device sync and a comment that it's on the roadmap, but low priority. If that gets implemented, I'm on board. Until then, it isn't feasible to ask a bunch of non-tech people top switch.
As a side note, who only ever uses one device? How can multiple device sync not be a core feature of every chat design? I find this baffling.
3That's why I recommend XMPP.
As of why multi-device sync isn't a core feature is due to the inherent nature of the SimpleX protocol that everything is stored locally, servers are only relays and do not store nothing more than heavily encrypted packages that only contains messages and once they are delivered, they are immediately removed. Servers do not store any information, they don't have your contacts, nor any form of unique identification for your account. You might even change the relay you're using every 5 minutes, because you aren't tied to them.
Compare that with XMPP where you're hosted in one server and all your messages and conversations go to that single server. Your server also stores your contact list for multi-device sync and because you're always using the same server for that account, it will work seamlessly. In SimpleX, your account information never leaves your device.
2Syncing between clients is still possible, although it may not be implemented. There's no reason why a P2P client that's part of a conversation can't request past messages from any other client that's part of that conversation. All P2P does is move the data handling to the edge.
This is what I was implying: if a chat design doesn't account for this, it's IMHO not a good useful design - especially in the case that the design also leaks some metadata, and so isn't 100% targetted at dissidents.
P.s. I'm going to write my own chat application, with blackjack, and hookers.
1
Another comparison is here: https://eylenburg.github.io/im_comparison.htm
2