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.