Also see [1], they have every bridge's features well documented.
Bridging chats of different technologies doesn't work well/at all (i.e. Signal bridge + WhatsApp bridge users in a single room) but bridging external chats (DM or group) into Matrix works very well. Some services need a daemon running on a phone (i.e. WhatsApp) and that's very annoying, but where possible these bridges all run in the cloud.
If you trust third parties, you can also go the easy route by getting a subscription from EMS (https://element.io/matrix-services/ems-pricing) or Beeper (https://www.beeper.com/). I personally prefer to keep my messages and encryption keys on devices I control, but others prefer to let someone else take care of it all and I respect that.
It's relatively straight-forward to set up a bridging server if you're comfortable with Docker and YAML files. You can read how to set up a Matrix server here: https://matrix.org/docs/guides/free-small-matrix-server and here: https://github.com/spantaleev/matrix-docker-ansible-deploy/b...
If you use the Ansible playbook, all you should really need to do is run through the setup, fire up a Matrix client, start chats with bot accounts, and follow the instructions on the guide (usually sending /login to a bot and authenticating your account with whatever service you're bridging).
Your Matrix account doesn't have to be on the same server as your bridges, which is a setup some seem to prefer. You can set up a Matrix server just for bridging so that you don't need to set up all the VoIP features and performance tricks while keeping your own server dedicated to just bridging stuff. This does break some nice features (i.e. double puppeting, a bridge feature) but it also makes your own server less of a single point of failure if you ever do get talking on Matrix.
on this paper: https://nebuchadnezzar-megolm.github.io/
Worth reading the response from Matrix as well (https://matrix.org/blog/category/security).
My first reactions are to wonder how many of these issues are associated with federated (as opposed to fundamentally decentralized) group chat in general. Matrix seems to be taking the position that some of these issues ultimately relate to trust vs lack thereof in the homeserver as a bottleneck.
I also wondered if there was a good security model for federated or decentralized group chat at all at the moment. I can't remember offhand if Briar was adding groups or not, but that's not federated.
The only practical issue raised by https://nebuchadnezzar-megolm.github.io/ which we didn’t already fix is the question over whether servers or clients should control group membership. Our position is that it’s okay for the server to control it as long as clients are warned if malicious users/devices are added. Fixing it properly is Hard: for instance, if you are chatting in a room and it turns out that a remote user kicked another remote user, but the kick was delayed in reaching you, you could keep chatting away encrypting messages for a user who is no longer in the room and theoretically should not be receiving them. Is this a security flaw? Or is this just how causality works? So we’re dealing with problems similar to that; hopefully we will be able to switch to client controlled membership by end of year.
tptacek’s derision is not very constructive.
https://matrix.org/blog/2022/09/28/upgrade-now-to-address-en...