Dendrite is still in beta, and hasn't been tuned that much yet, but every release has had a substantial improvement. In other words, if you're not using today's release (0.3.5) you're on stale data. For context, dendrite.matrix.org (running 0.3.5) has ~5K users on it, and is in ~3K rooms spanning 162K users... and its RAM usage is stable at 488MB (occasionally spiking to 2GB during traffic spikes). This doesn't seem unreasonable at all for a chat server of that size. Meanwhile, Synapse has been steadily improving too.
On the client side, Hydrogen (https://hydrogen.element.io, https://github.com/vector-im/hydrogen-web) is our next-gen client implementation, which gives you full E2EE, complete with backup (I have no idea what Durov is banging on about in the OP) - and uses 14MB of RAM for an account in 3,000 rooms spanning 350K users (i.e. my personal one). This is an 100x improvement on Element Web which uses 1.4GB for the same account, although there's also a lot of optimisation that can be done there too.
If I was going to criticise Matrix, I'd focus more on the fact that there are still a lot of papercuts on Element's UX which are holding us back. We're painfully aware of this though and are trying to fix as rapidly as we can.
As you haven't mentioned it: Supporting e2ee isn't enough. It must be the default, else the non-technically inclined will often end up not using e2ee.
>As much as I dislike to admit it, this leaves Matrix, and nothing else.
I'm in the same position. Never been a fan, but I have to support it, because that's really the only option, even if bloated.
I also tried running a server (synapse) with similar results. I have hopes for dendrite, but they've just been dampened by your report.
Fortunately, the client side is far more important, and there's some options there. Particularly, the web-based hydrogen is massively less resource-hungry than the web-based element, and nearly there featureset-wise.
>XMPP
I didn't even list that one, because e2ee is not the default, and support was added way too late in the protocol's trajectory.
>Signal
I mentioned it, but I'm actually not about to use it. The reason is that accounts are tied to phone lines. That's a non-starter for me.
That is not a thing with XMPP. The very essence of it is adding things in, and OMEMO is quite good.
It is with this knowledge that I cannot recommend XMPP.
e2ee should be at the core. Not as an entirely optional extension added decades after.
As I already stated, because I want the non-technical inclined to have privacy, I can only support options where e2ee is the default.
The "only" problem is that it isn't easy, and thus most people do not use them at all.
Therefore, I cannot recommend XMPP.
can't be many
Seriously... setting up your own email server. All users use a web client (there are tonnes out there, with the option of using thicker clients).
Bots can be used to organise the groups, add new users, etc.
Most people chatting to their friends and family don't need that level of security.
If you don't want China listening to you: don't use someone else's system.
When you get into groups with hundreds of members I think Slack and Discord are probably the dominant chat apps there.
As far as old messages goes, Matrix rooms do not allow new participants to see old history, unless explicitly enabled.
>if you have 250 people in the chat I'm not sure it'll be very effective. It only takes one of those people to leak the messages.
Ultimately, the system is only good when the members of a room deliberately leaking messages is the primary concern; It means the system is working as intended, thus privacy is a matter of trust on the conversation members, as it is away from keyboard.
I can't suggest XMPP to non-technical people, because I know they'll end up talking to each other with neither e2ee nor awareness of lack of e2ee.
and how is it achieved when you want that? Standard feature that is expected by people using Telegram, Matrix, Slack, etc.
Your own link mentions "Size limit of 1000", where did you see 150?
To be fair that's for new groups, maybe the limit used to be lower. Or do you mean that in practice it's not usable beyond 150 people?
https://wire.com/en/products/personal-secure-messenger/
And why's Threema out? You can hardly complain that there is no solution to your needs, and then, when one is offered, say "no need for yet another solution"...
Are there any popular XMPP clients that don't support "HTTP File Upload" at this point? I went looking for a list of those that do and had to give up. They all support it now.
On it's own, XEP-0363 (HTTP File Upload) and OMEMO both work well everywhere, even in my horribly overpatched Pidgin.
But if you put the two together, Conversations, for example, will encrypt the message and encrypt the upload as well.
My Pidgin then will handle the message well, but display an url starting with aesgcm:// leading to the still encrypted file.
The question is then: is the correct behaviour what of Conversations is doing - encrypt the message and upload as well? If yes, is OMEMO a requirement to HTTP File Upload or the other way around?
When you send a pic in a conversation, the content-type of the resource is "image/*". It doesn't matter whether the image is encrypted, compressed on-the-fly, or whatever, the receiving end must "undo" all of it to present the intended resource to the user
Most XMPP clients are plugin based as well. Should the OMEMO plugin then look for aesgcm:// urls, download it, and decrypt it, or should the http upload plugin look for the availability of encryption and try to decrypt?
There will always be hacky and badly implemented clients. It comes with the idea of an open specification. That doesn't mean we should use them as a point of comparison.
It has a single UI, so it's out. Wire specifically disallows anything 3rd party.
And an Android app that doesn't combine the slowness of iOS and Android would be nice. To be clear - their animations (to me) drag on too long (as one might say about iOS), and UI input takes a noticeable amount of time (which is commonly found on Android apps that aren't well-written).
While this may not be helpful for anyone looking to improve the apps, that's kinda more of the same point - nobody is allowed to make a better client, as it's against the Wire ToS. This is why there's no Matrix bridge.
Found Matrix, happy with it. It likely will adopt MLS, too.
PS: these days swiss based is a bit of a stretch
1) option for large groups (around 250) This drops Signal out which has a limit of 150 on groups: https://support.signal.org/hc/en-us/articles/360007319331-Gr...
2) e2e encrypted (because it sounds good, not because people actually understand what it is), including groups. This drops Telegram out: no e2e rooms.
3) handles sending photos, videos, and voice messages. More or less kills XMPP, unless people are on the latest-and-greatest version of Conversations and maybe ChatSecure.
4) the maintaining organisation needs to be reasonably big with decent privacy.
5) usable for completely non technical generic population - meaning Tox is out as well.
As much as I dislike to admit it, this leaves Matrix, and nothing else. My problem with Matrix is that it's so resource hungry - both the servers and the clients - is that it's silly. Yes, I know "optimization is coming" but even Dendrite eats 1.5GB memory easily with a single user joining a few, medium sized, federated rooms (yes, I've tried).
Footnote: Threema... no. There is no need for yet another competing open source thing, there are enough with Signal, Matrix, and XMPP.