Tonight, I’ve configured and set up a bridge linking my Matrix account to my Signal account. The bridge is an instance of Mautrix-Signal, running on my collective server. As such, it’s configured to work only with users of this server.

What does it mean? From now on, every message, reaction, media etc. sent to my Signal account will be forwarded to a mirrored Matrix room, where the Signal user has a Matrix “puppeted” equivalent user.

This has a few implications in terms of security, so if we belong in a Signal conversation together, please double-check your threat model after ingesting the security information below, and if you’re uncomfortable chatting with me on Signal, that’s fine; feel free to remove me from any conversation we had together (ideally, please let me know about it so I’m not totally confused 😁).

security implications

Matrix and Signal both use end-to-end encryption, but it would be too simple if the encryption layer was implemented exactly the same way, and thus was interoperable (although, this might be in the works, thanks to initiatives like MLS).

So, with this bridging enabled, the following happens:

• Signal messages will be relayed in encrypted form, from Signal to my server.
• The bridge software will decrypt it using Signal encryption, in memory.
• The bridge software will re-encrypt it with Matrix encryption.
• The bridge software will send it to the Matrix server, in its encrypted format.
• (Later, my matrix apps will receive the Matrix-encrypted message.)
• The message is then forgotten from the server; it only exists in clear form on my Signal apps and my Matrix apps, from this point.

This is breaking end-to-end encryption, since the message appears in clear-text during processing, for some short time, on my server. Some people call this paradigm end-to-bridge encryption. This is strictly better than keeping the messages in clear on the server, and I find the tradeoff worthy of my requirements and preferences.

Note that some metadata is encrypted in Signal, and is not encrypted in Matrix. This includes:

• user display names
• who are the members of a room, when did they joined, etc.
• who can do what, in a given room (post, invite others, etc.)
• a room’s name and description
• (everything that the Matrix specification calls “state events”, or also apparently “room events”)

Again, if this is a problem for you: it’s absolutely fine to remove me from any conversation we had in common. I’m still available via some other mediums, if needs be.

why?

As a long term Matrix user, I have always been interested in Matrix’s promise to replace most messaging apps. I already had a WhatsApp (evil but somehow encrypted) and a Telegram (just plain bad) bridge, which allowed me to chat with folks using these platforms. And these days, more and more people are moving over to Signal, for good reasons, so the number of Signal conversations started growing a lot.

This is something I’ve been wanting to do for a long while. Before, setting up the bridge required instantiating an Android virtual machine on the server, that would run the Android Signal app in the backbground. Now, this is not required anymore, because Signal can have secondary devices that are connected to the main app, and that’s great news.

conclusion

Overall, I’m quite happy that I could enable it in the matter of 30 minutes or so. With backfill enabled, I even obtained the history for the previous messages that were sent on Signal before enabling the bridge, which is super nice. Connecting my account added one room for each Signal conversation, so I received around 80 invites for new conversations, which took a bit of time to handle in the ElementX application (that I’ve been working on for almost two years!). Now I can mute (hopefully!) forever the Signal app’s notifications on all my devices, and mostly use only Matrix 😎