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.

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.

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.

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

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.

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.

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.

I've been using it for the last year straight and I think we only experienced one unforeseen breaking API change.

Just chiming in, I probably wouldn't pay for $10 a month for this service (maybe I'm not the target market). I do use various messaging apps and it is annoying though.

This jumped out at me:

>we send each user a Jailbroken iPhone with the Beeper app installed which bridges to iMessage

I couldn't tell if that was some sort of joke or if it meant something different to how I was reading it?

Being open source is great, but to be honest I lack the time (and expertise) to see how all the integrations work. A page that describes a high level overview of how this works exactly might build more trust.

Good luck!

I get the concern, but they're probably not super brittle because chat apps still need to support old clients. I'd worry more about getting blocked entirely.

I remember chatting with the Meebo founders about some of this. They didn't really have an answer to why AIM, YIM, and MSN Messenger wouldn't block them beyond it being bad for their networks. On how they'd make money, I don't remember hearing any interesting answers. They never really figured out the money thing and ended up getting acquihired by Google.

The did have a crazy-impressive web UI for the mid-2000s; for a while, that know-how was probably their most valuable asset. The need and the market still (and have always) kinda exited, but the players changed a lot in the last 15 years. One of their business ideas was to pivot into a commercial support chat app. People use them today, so maybe they were before their time, or maybe B2B was never in their DNA.

We had a bunch of IPs for each of our servers to get around some of their auto-blocking stuff. Eventually we got approval from AIM but that was fairly late. You're right in that we had crazy-impressive web UI but the backend was also unique in that we had a process running for every logged in user (and eventually we had a process running for every user who was running the iOS app)

Why would chat apps need to support old clients? If facebook pushes out an update almost every user will have it on day one and every user will 1 month on. They can just show an error banner to users who have automatic updates turned on.

My life as a developer would be much easier if every user actually upgraded their apps within a month of updates. In my experience, a substantial proportion of users either have automatic updates disabled and only manually update individual apps when they break, or don’t habitually connect their phones to Wi-Fi, and thus don’t get automatic updates.

It’s why apps like desktop Chrome have extremely aggressive automatic-update schemes which are near-impossible to disable if you’re ever connected to the internet.

You must have different users than I had.

iOS users upgrade pretty quick, but Android users don't. There are lots of phones with not very much storage, so upgrading is painful for users and they turn off auto-updates and don't update frequently.

And when you add on end of life platforms that have enough users you don't want to cut off, but not enough users that you want to do active development, or the platform owner won't sign packages anymore, you have to support some clients for a long time.