Matrix's encryption is based on the same cryptographic ratchet technology used by Signal. The protocols involved are called Olm and Megolm.
Olm is used for establishing 1-on-1 sessions between pairs of users (or rather, their devices). This is then used as a secure channel to share Megolm keys. A Megolm key is ratcheted with each room message sent and is used to derive a symmetric AES key with which the message is actually encrypted. Periodically (every N messages) a new Megolm key is created and re-shared with room participants.
So the end result is that it has roughly the same security as Signal, except that a single compromised Megolm key will reveal N messages to the attacker instead of just a single message. In return, the protocol is much more scalable, enabling relatively efficient large end-to-end encrypted groups. Otherwise, all the session self-healing, forward secrecy properties of Signal are retained.
TL;DR: Approximately the same as Signal, trading a tiny bit of security in the event of a key leak for more scalable encryption in the setting of large groups.
I believe this is true for Matrix-to-Matrix communication. However if I understand correctly the bridges terminate the e2e encryption and then connect to the third party service (possibly with a different e2e session).
you can self host the bridge between matrix and signal, allowing e2e to a host you control, and e2e from that host to your device. Perhaps not ideal, but likely unavoidable if you want an all in one app like this.
So, essentially, if I self-host the bridges then there's no security issue (otherwise it looks like a third party has access to the keys to decrypt messages, unless the negotiation just creates a tunnel through which the signal connection occurs)?
so the answer is: yes this reduces security over signal for both myself and whomever i’m chatting with. due to this, seems like a questionable choice to include signal.
I don't know much about Beeper, but I do know more about Matrix in general. And yes, the N is configurable there (as in, you can change it in a client implementation, even if it isn't particularly common to have it exposed as a setting).
Olm is used for establishing 1-on-1 sessions between pairs of users (or rather, their devices). This is then used as a secure channel to share Megolm keys. A Megolm key is ratcheted with each room message sent and is used to derive a symmetric AES key with which the message is actually encrypted. Periodically (every N messages) a new Megolm key is created and re-shared with room participants.
So the end result is that it has roughly the same security as Signal, except that a single compromised Megolm key will reveal N messages to the attacker instead of just a single message. In return, the protocol is much more scalable, enabling relatively efficient large end-to-end encrypted groups. Otherwise, all the session self-healing, forward secrecy properties of Signal are retained.
TL;DR: Approximately the same as Signal, trading a tiny bit of security in the event of a key leak for more scalable encryption in the setting of large groups.