Hacker News Reader

Matrix's resource utilisation is improving very rapidly at the moment.

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.

Hydrogen looks extremely promising due to its low resource usage, but urgently needs an easy way to verify its session from Element and easily migrate its keys.

>2) e2e encrypted

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.

> it was added way too late in the game.

That is not a thing with XMPP. The very essence of it is adding things in, and OMEMO is quite good.

I'm well aware of how XMPP works as I've been using it from the start.

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.

try having verified e2ee conversations with XMPP - good luck.

Doing it actively. Try Conversations.

how many contacts with how many devices do you have there?

can't be many

I've been having them for over a decade.

The "only" problem is that it isn't easy, and thus most people do not use them at all.

Therefore, I cannot recommend XMPP.

About XMPP, it's a protocol. So it's possible for there to be a client with e2e by default right? And the problem is there is no reasonable client like that right now, right?

How about email?

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.

By the way before anyone shouts at me, I know email isn't E2E encrypted. As I've said before on HN: if you are looking to communicate securly, you shouldn't be using anyone else's infrastructure. That includes Signal et al.

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.

You could even allow only emails to the same domain (handled on the same server itself). Then emails never leave the server, and people can access them with their favourite tool, such as web or IMAP/SMPT, which encrypts everything in transit these days, if set up properly, unless I'm mistaken.

I recommended it heavily, got dismissed immediately.

I'm all for end-to-end encryption, but 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.

When you get into groups with hundreds of members I think Slack and Discord are probably the dominant chat apps there.

Indeed. But ever since Whatsapp started advertising e2e, people want it.

Well I'm glad to hear that e2e is a feature that's in demand. :)

That is not a good approach. Every piece of technology has it's place; requiring 2e2 encryption in a group of hundreds is a bad requirement.

Non room members shouldn't be able to read the text in the room. That's quite basic.

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.

Neither does XMPP, given it doesn't store it ;)

But XMPP has the non-trivial problem of e2ee as an extension added very late and not the default.

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.

> Neither does XMPP, given it doesn't store it ;)

and how is it achieved when you want that? Standard feature that is expected by people using Telegram, Matrix, Slack, etc.

Not by the people used to WhatsApp. That doesn't do it either.

> This drops Signal out which has a limit of 150 on groups

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?

The page seems to have been updated recently to say 1000 instead of 150, definitely less than a month based on archive.org

3 days ago it was 150, I swear.

Well, it seems to be time to revisit your decision then!

What about Wire (groups up to 500, e2e, handles photos etc, Swiss firm, easy to use)?

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"...

>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.

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.

Well... that's complicated.

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?

Encrypting the message AND the upload seems a no-brainer to me, if you want to call it E2EE. If the upload would not be encrypted then the (admin of the) server running XEP-0363 HTTP File Upload could see the contents.

I agree. The part I don't see is then what plugin should handle which part, and how.

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?

Client authors should do what Conversations do. End users should probably stick with Conversations, for now.

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.

That is only a question if HTTP upload and OMEMO are different plugins. With https://dino.im/ it also "just works" and as a user I do not care which part pf the program does what.

I feel like encryption before payload and OMEMO are 2 different layers like, say, TLS compression and HTTP compression.

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

Have you heard about Wire? Groups up to 500, when they switch to MLS protocol then thousands, e2e, Swiss based and it has kind of ok UI.

> has kind of ok UI

It has a single UI, so it's out. Wire specifically disallows anything 3rd party.

App is available on Android, iOS, Mac, Win, Linux though - what more do you need?

A web-app that doesn't log me out every time I reboot, then warn me I'm "already logged in".

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.

uninstalled it after I lost all history, because I didn't open the app often enough.

Found Matrix, happy with it. It likely will adopt MLS, too.

PS: these days swiss based is a bit of a stretch