For those who don't know - Eric's new company, Beeper [1], is a proprietary Matrix chat client with hosted Matrix bridges to other chat platforms. The bridges are open sourced which is a huge contribution to the Matrix ecosystem.
The big selling point for Signal et. al. is knowing that corps/govs/etc can't spy on my conversations. If I was going to give another app permission to use my Signal, I'd need assurances I'm not sacrificing my security.
But then _you_ need to make sure it's available 100% of the time?
Sorry to hijack the thread, but from the above link:
> Yes, iMessage works even on Android, Windows and Linux!
How could this be sustainable long-term? I've hacked together tools to forward iMessage content before and it's very unappealing.
I suspect they must be using a makeshift solution. I hope it works (and would sign up if there was a way on the landing page), but this seems like building on sand.
It works fine for me so far, though there's no out-of-the-box solution for forwarding iMessages that go to your phone number. That requires extra hackery.
That's the bridge Beeper uses. I've got it running on a 2011 MacBook Air on MacOS 10.13, almost zero issues.
Some smart people are running this, that's for sure.
Anyone know?
Texts looks entirely proprietary and the FAQ says they're working on an iOS app.
Texts was too buggy for me to keep using. I still think it has potential though.
Matrix.org also has an XMPP implementation (see https://disroot.org/en/services/xmpp), but it was quite unreliable when I tried it.
I'm digging it so far.
But it also means compromising on your designs, I think, because I'm fairly sure it's a lot more difficult to implement a custom design on a Linux app. And Apple MacOS apps have certain design guidelines and Expectations as well.
I wonder if they could make this into more of a client-server architecture; a crossplatform server that runs as the back-end on the user's machine (or an embedded core), and a native client implemented for the specific OS. With an open protocol so that the community can build alternative clients, e.g. CLI based, or native with less bells and whistles, or more compact.