[larma]

I think implementing just the e2ee part of the WhatsApp protocol (which happens to be the Signal protocol with open-source libraries available) client-side and have a server-side bridge transport the encrypted messages over to WhatsApp and vice-versa is a sensible option not mentioned in that blog post. Yes, worst-case it means that for interoperability you have to create a bunch of message encryption routines. But we are effectively talking about iMessage and WhatsApp - Facebook Messenger doesn't do e2ee and no other company that built a widely used personal IM system is big enough to be covered by DMA.

Regarding moderation and spam: I think a company with €7.5B yearly revenue should be reasonable able to build something such that moderation and spam prevention are also possible with federation. Google already does a pretty decent jobs in spam filtering with e-Mails, I guess they should be able to do something similar with IM.

[uncomputation]

The post did mention this:

> We could run the bridge somewhere relatively safe - e.g. the user’s client

What is the advantage of having a server-side bridge then? Just do everything client-side.

[Arathorn]

Clientside bridges are hard to run as mobile OSes don’t like background apps due to the risk on battery life. So if you installed a little shim WhatsApp client which speaks to the newly open WA APIs and relays everything back and forth to Matrix, getting it to run reliably could be fun.

[larma]

The complexity of a whole protocol and running a client for it (which is effectively what you are doing when running bridges locally) is much higher than just doing the necessary part (e2ee) on the client. Also, you might be unable to run such bridge in a web client because the protocol is not based on cors-enabled http/websocket APIs.

[uncomputation]

I see, thanks.