The EU Digital Markets Act is here.

🇪🇺 Happy DMA day, everybody! 🇪🇺

March 7th 2024 is the deadline for large messaging providers (so called ‘gatekeepers’) to comply with the EU’s Digital Markets Act regulation, which requires them to offer interoperability to third party messaging services.

This lets users use their preferred messaging service, rather than being obligated to use the same service that their contacts happen to be on.  In turn, this keeps the messaging market vibrant and healthy, as messaging services then have to compete by providing concrete benefits and features, rather than simply leveraging the network effects of their userbase to grow even bigger.

We’ve been following the DMA journey for over two years, and between the Element and the Matrix blogs the full coverage spans:

• Feb 2nd 2022: Digital Markets Act and interoperability: Debunking the gatekeepers' myths
• Feb 28th 2022 Interoperability: Open APIs are a start, Open Standard is better
• March 25th 2022: A Big Step to address Big Tech
• March 25th 2022: Interoperability without sacrificing privacy: Matrix and the DMA
• March 29th 2022: How do you implement interoperability in a DMA world?
• March 30th 2022: Technical FAQ on the Digital Markets Act
• April 8th 2022: The Digital Markets Act explained in 15 questions
• April 8th 2022: A guide to navigating the Digital Markets Act
• March 15th 2023: The DMA Stakeholder Workshop: Interoperability between messaging services
• Feb 4th 2024: FOSDEM 2024 - Opening up communication silos with Matrix 2.0 and the EU Digital Markets Act

And now it’s finally here! So, what does this mean for you?

Firstly: the only messaging services currently considered a DMA Gatekeeper are WhatsApp and Facebook Messenger.  Unfortunately Apple has wriggled out of their obligation so far, by claiming that iMessage has insufficient use in the EU to qualify… while coincidentally promising to implement RCS in iOS.  Apparently Google Messages, Skype and other services also do not meet the usage thresholds either.

Meanwhile, Meta has published the details of how DMA interoperability will work for WhatsApp on their engineering blog - and have launched their nascent DMA developer portal. Most importantly, this provides their Reference Offer (the proposed contract which interoperating parties would need to sign to interoperate with WhatsApp); high level Developer Documentation Overview; and Application Guidelines and the actual Application form for organisations wishing to interconnect.  It looks like the fine detail of the developer documentation may require an NDA, which could be problematic for those wishing to write open source bridges (or contribute to unofficial bridges).

Element has been working with Meta since the end of last year to help test their DMA interoperability (given we’re probably the world leader in interoperable end-to-end-encrypted communication) - and Matrix announced last month at FOSDEM that Element has successfully integrated 1:1 chats between Matrix and WhatsApp via the DMA APIs, while maintaining end-to-end encryption (having implemented full Signal compatibility in vodozemac).  We’ve also formally requested interoperability with WhatsApp, as of yesterday.

However, we’ve not moved to put the existing integration live yet, as we still need to solve some of the points outlined below - and we’re also waiting to understand some of the finer details of the user experience. After all, the devil is in the UX details for user-facing functionality, which could make or break whether interoperability is actually usable in practice or not.

The biggest concern right now is around “reachability”: whether DMA interoperability will default to off or on for EU citizens - and so whether users on Element would even be able to contact users on WhatsApp without the WhatsApp user having to explicitly opt in in advance.  According to the public information available at WhatsApp Chats Will Soon Work With Other Encrypted Messaging Apps | WIRED on Feb 6th: “WhatsApp users who opt in will see messages from other apps in a separate section at the top of their inbox.”.  We all know the power of defaults, especially when applied to competition law, and we’re interested to see what the final user experience is.

Another big concern is around the privacy impact of anti-abuse mechanisms. WhatsApp’s blog post explains:

The challenge here is that WhatsApp would no longer have direct connection to both clients and, as a result, would lose connection level signals that are important for keeping users safe from spam and scams such as TCP fingerprints. We would therefore anticipate implementing additional requirements for third-party providers who take up this option under our Reference Offer.

Now, it’s great news that WhatsApp are supporting what they call a “proxy” or “intermediary” architecture - or what we’d call a “bridge” in Matrix parlance, where the connecting service runs a E2EE-preserving bridge to convert existing traffic (Matrix) into WhatsApp’s proprietary APIs. However, it’s unclear what “additional requirements” WhatsApp have in mind - but options which expose personally identifying data of Matrix users to Meta are obviously not going to be viable.  Currently the Reference Offer doc has:

7.6.2.4. Proxy must provide the relevant Client's IP Address to the WhatsApp Infrastructure upon establishing a Proxy Connection.

and

7.6.3.4. Proxies must not buffer or otherwise, hold or delay Messages

…both of which are clearly problematic when bridging to Matrix.

On the plus side, the Reference Offer explicitly allows using alternative Signal Protocol implementations to integrate (i.e. vodozemac in interolm mode), albeit at WhatsApp’s discretion:

2.1.2. at the sole risk and liability of Partner, an alternative encryption protocol that has been approved in writing by WhatsApp (at its absolute discretion) and subject to any validation requirements, policies and conditions of such approval specified by WhatsApp, and provided such alternative provides materially the same level of encryption as the Sublicensed Encryption Software.

From reading the developer documentation, it’s clear that Meta’s default stance has been to simply open up their existing APIs for third party clients - effectively supporting interoperability by adding WhatsApp support to existing apps by acting as a multi-headed messenger (or “polyglot app” to use our terminology from the March 2023 DMA workshop).  However, support for bridging is welcome, as it should allow a provider like Element technically to run a bridge through to a protocol like Matrix - effectively supporting open standard based DMA interoperability:

That said, if WhatsApp traffic can be bridged via DMA to speak Matrix, it’s unclear on whether such a bridge can connect to the wider Matrix network - or just to servers run by the Requesting Party (e.g users on Element-hosted servers, in a world where Element has requested interop with WhatsApp).  On the plus side, this could still allow developers to use Matrix as a mature, stable standards-based E2EE API to talk to WhatsApp rather than having to implement a proprietary WhatsApp client stack.  But on the minus side, it wouldn’t be a free-for-all official bridge between all of Matrix and WhatsApp.  This probably reflects the wording of the DMA, which is designed to let competing businesses interoperate with gatekeepers - but doesn’t say anything about open federation with decentralised communication networks.  However, we’ll see how this plays out in practice!

Another limitation in the developer documentation is…

Note: Only one encryption identity can be associated with a Partner user account at any given time. Therefore, WhatsApp clients only encrypt messages to a single device.

…which is understandable, given plain Signal Protocol is strictly a one-to-one device approach, and solving multi-device interop would be the same problem as solving multi-user chat interop, which is scheduled for 2026.  However, it will certainly lead to some user experience challenges, given how used users are to multi-device synchronised chat on both Element and WhatsApp.  There may be ways to securely work around this limitation on the Element side, however.

So, in conclusion: this is the beginning of an interesting new chapter.  We’d like to thank Meta for working constructively with us while we’ve been testing their DMA APIs, and taking our feedback under consideration. If nothing else, this is a massive step forwards for open third party APIs - but we also hope it will prove a step towards true open standard-based interoperability too in the longer term.

Meanwhile, WhatsApp’s Reference Offer is a pretty dense 47-page document, and we’ve only just started digging into it. We’ll update here as more clarity or challenges emerge on how DMA interoperability may work for Element and Matrix in practice, so watch this space.