> Instead, I now have FB Messenger, WhatsApp, iMessage, Discord, and Signal all running and taking up space in my dock.
Why don’t you use a matrix client with bridges? I use telegram, WhatsApp and signal over Element. The bridges are not as great as the individual clients, but it’s definitely miles ahead of using five messaging apps.
Maybe I'll look into it more, but it feels messy and complicated at first glance. Portal rooms, plumbed rooms, bridgebot bridges, Bot-API bridges, puppeted bridges, double-puppeted bridges, server-to-server briding, and sidecar bridges. I haven't used it so some of this may be wrong and I'm happy to accept corrections.
It seems like a puppeted bridge requires me to send the messages to the Matrix server who then has a login to my FB Messenger to read/write messages there. I'm not going to run my own Matrix server so that requires me to trust a Matrix server with access to my Facebook.
Yes, downloaded apps can be malware, but it's a lot more easily discoverable. One can use tools like Wireshark to confirm where data is going. If apps are open source, one can see the source code and even compile one's self. Even if you don't trust the maintainer who is compiling, you still have a good idea that they're not sending all your messages to them because someone is more likely to notice the binary doing that (via tools like Wireshark). When software is just run on a server that the public doesn't have access to, who knows what is happening. Yes, running on your machine doesn't mean everything is safe, but there's some level of inspection you can do of what is going on.
I don't want to sound too down on Matrix, but it feels a bit off to me. It feels like people who want a decentralized future...where everyone is centralized into a small number of servers who can run a dozen or so Docker containers and such. Maybe that's the way the world needs to be given where we're at, but I just miss having a client that could login to multiple chat services.
If these puppeted bridges can exist, why can't my client just puppet directly? Why send the message to the matrix server for the matrix server to then call the Facebook API? I remember the days of AIM breaking the OSCAR protocol and libpurple/libgaim needing to catch up so I understand that pushing out an update to client software might mean some extra hiccups in the connectivity. Still, it feels like the servers might not be able to update their software much faster than I am able to. Maybe App Store approvals holding up updates is the issue? Is the issue that app stores could block a Matrix + bridges client since it's clearly trying to access services that don't want third-party access, but a Matrix client that's just talking to a Metrix server is fine - and then the "infraction" is on a server that the App Store doesn't get a say over? (I'm not saying that I think it should be disallowed, but I could see companies disliking it)
Is the issue that people want to write these bridges in JavaScript, Python, and other languages which are all fine if you're running a bunch of Docker containers on a server, but might not work so well if you're trying to create a desktop or mobile app?
Why can Matrix bridge these things, but we can't have a libpurple that works as well as these bridges? Or maybe I just haven't used libpurple in a long time and it's actually still good and I should re-try it.
It feels like Matrix wants to be a decentralizing force, but then the bridges force me to centralize my messaging through one of their servers. Again, maybe that's the way it needs to be for reasons, but it just doesn't feel like what I've been looking for.
> Maybe that's the way the world needs to be given where we're at, but I just miss having a client that could login to multiple chat services.
I'd be very curious to know if the work on P2P Matrix servers is going to include some level of support for client-side bridges?
I know the P2P work and bridging aren't quite the same thing, but it seems like the two are vaguely related: if you've got a bridge running, I suspect that would have a lot of the same concerns as running a Matrix server locally. And I get that for some clients like iMessage, your bridge has to be running on a Mac, but that isn't the case for most other messaging platforms, is it?
You don't need to know most of those things to get started, in general you can just follow the setup instructions for the services you use.
You do need your own homeserver, but for me I run a homeserver just for the bridges, and have my main account on a third-party homeserver. This way at least my native matrix chats (which are far more important to me) don't depend on my home server being online.
I would subscribe to hosted bridges fairly quickly if they were a reasonable price. Maybe $1/month per service? Obviously there is risk here because you are trusting someone with access to your account but to me it is probably worth it. There is https://www.beeper.com/ but you need to move your primary account to their service, which is just too much disruption and lock-in for me.
TL;DR I agree, self-hosting is a bit much. I'd love to be able to pay for it though.
I thought about hosting that service myself but I wouldn't want to run a service that is both against the dependencies' ToS and is playing cat-and-mouse with their attempts to shake you off. Too much excitement for too little reward.
> It seems like a puppeted bridge requires me to send the messages to the Matrix server who then has a login to my FB Messenger to read/write messages there. I'm not going to run my own Matrix server so that requires me to trust a Matrix server with access to my Facebook.
This is kind of how it's done today but also not exactly. The bridge (which is what has access to your account and messages) is its own process and could in principle be run on a separate host (like your own device for a single-user bridge). However, most (all?) public homeservers access for connecting puppeting bridges (meaning "virtual" Matrix identities for each identity on the bridged network, rather than just having a single "botuser" for all conversations through the bridge) and the API for access is rather coarse.
Also, last time I checked most bridges do not implement E2EE and signing properly, which means that the homeserver it connects to both gets read-access to bridged messages and can impersonate. This is mostly a matter of implementation not being prioritized highly in bridge projects. Currently that can be worked around to get E2EE even for cleartext bridges by running a protocol-specific proxy called pantalaimon which sits between the bridge and the homeserver and terminates encryption.
There are tradeoffs that can be made, which can be seen in the different alternatives for IRC bridges. For example, matterbridge is more of a typical bot (supporting loads of protocols!) and can be run towards a remote homeserver as a normal user.
I am certain we will see better interfaces to allow people to run local personal IM bridges without the requirements and overhead involved today. Thinking out loud here, I could imagine a minimal per-user homeserver baked into a client, that only does bridging for that user and only federates with the homeserver of that users' accounts. That could tick all the boxes even before P2P matrix I think.
The benefit of this approach over pidgin or a purely local single-user homeserver (which are viable and it sounds like you kind of want) would be all the conveniences people have gotten used to with centralized platforms... E.g. if you have the bridged rooms on a remote homeserver, seamless retention of histories across all your devices, without needing to be simultaneously online. But you'd also only need to keep credentials local, and message content in cleartext would only ever be acessible on your client(s).
I tried matrix bridged to IRC (libera) a while ago. It didn't sync back to matrix properly when people on irc left the channel, so you'd try to talk to someone on irc who wasn't there anymore. One time, a person on irc couldn't see any messages by any matrix users until they reconnected to the Network. And IRC is an old, open, well understood protocol. I just cannot imagine that a bridge to eg Whatsapp would result in anything even remotely usable.
To be fair your first problem sounds like an impedance mismatch more than anything else. Users come and go from IRC all the time because connections are transient by nature. It would probably be annoying to a lot of people if they left the room every time they disconnected.
Matrix and WhatsApp are both durable with regards to users so this issue probably isn't relevant.
Personally I find the biggest problem with puppeting is the impedance mismatches. For example if reactions aren't bridged it can be easy to miss stuff. This depends on the bridge used.
This is honestly the problem with a lot of these type of FOSS replacement products. It's not an "impedance mismatch" and the user isn't "holding it wrong", the product has bugs. They need to be acknowledged as the bugs they are and addressed, because the fact is of you want to replace a product you need to not be worse than that product.
Honest question: when registering for those bridges is it just as simple as putting in your username/password or do you have to do other gyrations to make it work? Do you have to upgrade continually to avoid the services playing whack-a-mole with your bridges?
I ask because I’d like to set up Matrix bridges like that locally, but if I have to create a Discord bot account or fish out an API key then that’s asking a bit much.
It depends on the bridge and protocol. IRC is as straightforward as any other IRC client. WhatsApp needs to run an actual WhatsApp client so you'll need an online iOS/Android device or run it a VM or emulator. Not sure about Discord.
EDIT: If you can do without Discord DMs, you don't even need to run the bridge yourself or supply discord credentials - just invite a bot to a discord server if it isn't already
Why don’t you use a matrix client with bridges? I use telegram, WhatsApp and signal over Element. The bridges are not as great as the individual clients, but it’s definitely miles ahead of using five messaging apps.