Comment by jeroenhd | Hacker News Reader

Comment by jeroenhd | Hacker News Reader

Parent Full thread

I'm running several of the mentioned integrations on my own server (without the Ansible script) and every now and then there's a weird bug, or some slowdown, or some messages not getting through, but I've mostly switched.

I'm not sure if I'd ever pay $10/mo for a service whose main selling point is running what are essentially reverse-engineered hacks. Some of the integrations use the official available API (like the Telegram one) but others (like the Whatsapp and Signal ones) run on altered web client code. Furthermore, in most commercial chat systems, alternative clients are usually not allowed and can lead to a ban of your account if the server considers you a bot.

The product is a worthy attempt at fixing the mess that is modern chat solutions, but from my experience I just don't trust the system enough to switch.

Also keep in mind that any e2e encryption platforms like Signal and Whatsapp provide is made worthless if you use a bridge; I haven't seen any bridge use Matrix's e2e encryption yet and your messages are all being decrypted on the server regardless.

All of our bridges (except Slack and Discord, but will soon) use Matrix's e2e encryption scheme and all messages are stored encrypted on Beeper servers with a key that you control. We can't decrypt your messages.

Thanks! This is the only piece of information I needed before giving Beeper a chance. I could not find it on the Beeper home page as a callout or in the FAQs, and it would probably be good to add.

Ideally I would not want to run the whole stack if I understand how the E2E encryption is managed.

Wait, how is this possible? There's an obvious integration point between your bridge server and the other service. They don't talk the same encrypted protocol, obviously, so you have to send plain text at some point in that process.

It makes zero sense that you don't have access to the messages.

Yes, I was wondering about exactly this! A dev response would be much appreciated.

They don't talk the same protocol but that doesn't prevent them using compatible forms of message encryption.

If the basic concepts of "E2E key exchange" and "pass this encrypted message" exist at all points, I see no fundamental problems with having E2E encryption across different networks. I can see potential for lots of the normal practical small problems but it could fundamentally work.

I agree that it's technically feasible but that's not going to help me right now. It would require all services use the same encryption (or at least understand a common, compatible one) and I don't see that happening, ever.

This simply cannot be true, since you have to decrypt the messages to send them to, for example, WhatsApp.

Nope - you have to encrypt them to send them to WhatsApp. Why could you not encrypt them in the client and then send that encrypted message over the bridge, preserving E2E?

Because that's not how this works. The bridge has to have the unencrypted text, because it's the bridge that is communicating with WhatsApp/Signal/IRC/whatever. The client isn't the bridge, it's not communicating directly with WhatsApp, it's just communicating with a Matrix Bridge (over an encrypted channel) to a Synapse server you don't control.

You'd need WhatsApp's collaboration for this, which I'm going to go out on a limb and suggest that the bridge operator doesn't have.

There are two encrypted channels: client<->bridge, and bridge<->WhatsApp. The bridge can read the decrypted text, and the comment I replied to is a lie.

Seems like you have to unwrap the message from the upstream scheme and re-wrap it in Matrix’s scheme at some point, right?

I’d appreciate a blog post explaining the architectural choices here.

Reply on news.ycombinator.com