Should we add Slidge XMPP-WhatsApp bridge to Durare?

Just to clarify, since there was confusion about this: the "bridge" we are talking about here (technically, "transport") is to make your personal WhatsApp account accessible over XMPP (and thereby access direct and group chats that you are connected to through your WhatsApp account). A WhatsApp account is necessary to use this bridge.

It is different from bridges like Bifrost that relay messages between two groupchats on different protocols, where it is sufficient to have an account on only one of the two protocols.

This information might affect some peoples' decisions in this vote.

Why the difference?

Bifrost is possible because both XMPP and Matrix (that it bridges between) are both federated networks allowing anyone to start their own server and host accounts. Technically speaking, Bifrost implements the "server-to-server" side of both the XMPP and Matrix protocols. If a Matrix user sends a message, it "creates" a corresponding XMPP user to send that same message to the XMPP side, and vice versa. We call these "created" users puppets because they are being controlled from the other protocol.

By contrast, WhatsApp does not allow a second party to "create" accounts: every account in WhatsApp has to be authorised by Meta themselves. This means it is not possible for a bridge software to create puppet users.

If you want a Bifrost-style bridge to WhatsApp, the best that can be done is to create a special WhatsApp user for the bridge to use (eg. +91XXXXXXXXXX) that joins every group chat. Whenever a message comes in a WhatsApp group, it can create a puppet XMPP account just like Bifrost does and show the messages as coming "from" that puppet XMPP user. However, when a message comes in an XMPP group, it will have to send a message from the same +91XXXXXXXXXX user and use some workaround like prefixing the message with "[person] on XMPP said:" This won't be a very great user experience on WhatsApp as every message from the XMPP side will be "from" the same one user.

In practice, even this would not be sustainable as WhatsApp would detect a single account (the bridge one) as sending a disproportionately large number of messages, causing it to be blocked as a spammer.

So what does Slidge do?

With Slidge, you would register your WhatsApp account with Durare's Slidge instance, allowing Durare to sign in as a "client" using your account. Because it's easy to create puppet accounts on the XMPP side, all your WhatsApp contacts and group chats would be visible to you over XMPP in the form something@wa.durare.org.

When you send a message to +91XXXXXXXXXY@wa.durare.org, Slidge will forward that same message from your WhatsApp account to your contact +91XXXXXXXXXY (and similarly for group chats).

What about encryption?

Since WhatsApp does not support OMEMO, it is not possible to send end-to-end encrypted (E2EE) messages via Slidge.

E2EE means the message in encrypted on the sender's device and decrypted only on the receiver's device, with no decryption happening in between. The purpose of this is that the server is not able to read the contents of your messages.

In the case of Slidge, it has to be able to read the contents of your messages to be able to forward them to the other protocol (otherwise you will get something encrypted in the WhatsApp encryption format that your XMPP client can't decrypt, and vice versa). Because of this, Slidge will keep control of your WhatsApp keys and use them to decrypt incoming messages before forwarding them to XMPP.

On the XMPP side, my guess is that Slidge doesn't bother encrypting the messages since there is no point in pretending to do E2EE when it isn't actually E2EE in practice. But perhaps it does it to please clients that insist on E2EE everywhere; I am not sure about that 🙃

A small note about the privacy implications

Though the setup is not E2EE because the Durare server can read the messages, they would still be encrypted such that the WhatsApp server can't read them. However, I wouldn't put too much faith into this as Meta can still read the messages after they've been decrypted on the recipient's device. Since Meta (probably) controls the WhatsApp app as well, nothing stops it from telling the app to transmit the messages to the server after it's passed through "E2EE" and been decrypted. Of course, the same logic applies at higher levels like the risk of Gemini or Microsoft Copilot reading your private messages after they've been decrypted on an Android or Windows device.

Assuming you trust the Durare server but want to prevent other parties from reading your messages, the best way is to use an XMPP app on a Free Software OS like Debian or postmarketOS to access the WhatsApp bridge and get your friend to also set up the WhatsApp bridge and access it via XMPP from a Free Software OS like Linux Mint or GrapheneOS. At this point, one might as well do away with the bridge and use XMPP directly.

Which is, of course, the progression of which I hope "setting up a bridge" will constitute the first small step.

TL;DR

To use the proposed XMPP-WhatsApp bridge, one will need to have a WhatsApp account and give Durare full access to read and send messages from that account. Further, these messages will not be end-to-end encrypted even if WhatsApp users are fooled into thinking they are.

@Badri Sunderarajan In theory Slidge can also keep omemo keys of the puppet users to enable encryption from user to bridge to make clients that enable omemo by default happy, but tls already covers that kind of encryption in practice.

@Pirate Praveen yes, that is what I was referring to in the encryption section:

But perhaps it does [encrypting of messages] to please clients that insist on E2EE everywhere; I am not sure about that 🙃

Also I think we should not let people who don't want to use bridge to stop people who want to run them as long as it meets the basic criteria, being Free Software and someone taking responsibility to maintain / raise funds. Because wanting to stop someone else from doing something we don't like is more attractive option for many people compared to building something they want. So we should protect people who wants to run Free Software things as long as they take full responsibility for it. May be we can create sub groups to take responsibility for specific things. So the question should rather be, are we philosophically opposed to bridges as a community? This could come in handy if someone wants to run a bot for publicai.co, what is the minimum criteria for Durare community?

@Buster Keaton this transport has been set up, right?

I wonder if it would be worth setting up a Telegram transport too. Slidge supports that as well so it would just be a matter of configuration.

We could have people coming after the Telegram ban.

FOSS United is rethinking their policy of using Telegram, so if we offer the bridge for them to experiment with maybe it'll help them shift to XMPP (for long term usage, we can see if they can help us with hosting expenses or help them set up their own transport)

If this was present during the ban, we might have been able to create a situation of "come for the Telegram workaround, stay for the federated XMPP messaging"

@badrihippo WhatsApp-XMPP Bridge has been set up. Telegram is no longer banned in India. If there are any user requests, then we can install it.