Implementing Interoperability for the DMA
matthew@matrix.org | amandine@matrix.org@matthew:matrix.org | @Amandine:matrix.org
1

Interoperability Implementation Options
1

2

Client-side bridging
using server-side APIs

Client-side bridging
using client-side APIs

3

4

Polyglot app

Gatekeeper switches
to open protocol● These options can be implemented in a standalone manner or seen as a transition towards a full
implementation of an open protocol.

● In this presentation we made the choice of using an open protocol (it could be Matrix, MIMI, XMPP, RCS,etc…); but all these options are valid with any protocol, including closed ones.** Not using an open protocol only means that if one player requests interoperability with several gatekeepers, they will have to implement the choseninteroperability option for each of the gatekeeper’s protocols they want to interoperate with, and precluding option 4.

2

Problem to be solved●

Walter is a WhatsApp (gatekeeper, GK) user anddoesn’t care about interop.

●Martin is a Matrix (requesting party, RP) user, butdoesn’t want to install WhatsApp.

We want Walter and Martin to be able to speak to one
another.

Martin’s device
Matrix
ClientMatrix / MIMI
network

Matrix / MIMI
network

Matrix /MIMI Server

WhatsApp Server
Walter’s device
WhatsApp
Client3

1 Client-side bridging using server-side APIs●

Bob is a WhatsApp user and wants totalk to people who are not on
WhatsApp:Martin’s device
Matrix
Client➡ Install a bridge app to expose his

Matrix / MIMI
network

WhatsApp account to other users.
●

Charlie has a WhatsApp account but
doesn’t want to use the WhatsApp app.
➡ Install a bridge app to connect his

interoperable client to his WA account.

Bob’s device

Charlie’s device

WA Bridge
AppMatrix
ClientWAAccountWhatsApp
ClientMatrix / MIMI
network

Matrix /MIMI Server

WA Bridge
AppWAAccountWhatsApp Server
Walter’s device
WhatsApp
ClientGhost WA accountfor Martin

WhatsApp: client-side bridging using
server-side APIs

4

1 Client-side bridging using server-side APIs
What itmeans forthegatekeeper(GK)What itmeans fortherequesting
party (RP)
What itmeans forthe users● The GK needs to expose theserver-side APIs allowing the RP todevelop a bridge● The GK needs a way to represent
remote users● Simplest / quickest to implement,
pragmatic but ugly
● The RP needs to source andadvertise a bridge

Martin’s device
Matrix
ClientMatrix / MIMI
network
Bob’s device
WA Bridge
AppWAAccount● GK’s users can install the bridge toexpose themselves to the RP’s users● RP’s users can install the bridge toconnect to GK’s users (need anaccount on the GK’s network)

WhatsApp
ClientCharlie’s device
Matrix /MIMI Server

Matrix / MIMI
network

Matrix /MIMI Server

Matrix
ClientWA Bridge
AppWA
Account

WhatsApp Server
Walter’s device
WhatsApp
ClientGhost WA accountfor Martin

WhatsApp: client-side bridging using
server-side APIs

5

2 Client-side bridging using client-side APIs
iMessage Server
Iona’s device

Ghost iMessage
accounts forremote users

iMessage
Client●Iona is an iMessage user who wants tocommunicate with non-iMessage users,
or use another app to / user interface tocommunicate.
➡ Install a bridging app which connects

iMsg
Account

iMsg
Bridge App
Matrix / MIMI
ServerMatrix / MIMI
network

Bob’s device

directly to her local iMessage client.
WA BridgeAppWA
Account

WhatsApp
ClientMatrix / MIMI
network

WhatsApp ServerWalter’s device
WhatsApp
ClientWhatsApp: client-side bridging using
server-side APIs
iMessage: client-side bridging using
client-side APIs

6

2 Client-side bridging using client-side APIs
iMessage Server
Iona’s device

What itmeans forthegatekeeper(GK)● The device’s operating system has toprovide an interface for the client-sideAPIs● The GK keeps their app as it is, otherthan exposing the client-side APIs
allowing the RP to develop a bridge● The GK needs a way to represent
remote users

What itmeans fortherequestingparty (RP)● The RP needs to source andadvertise a bridge

What itmeans forthe users● GK’s users can install the bridge toexpose themselves to the RP’s users● RP’s users can install the bridge toconnect to GK’s users (need anaccount on the GK’s network)

Ghost iMessage
accounts forremote users

iMessage
ClientiMsg
Account

iMsg
Bridge App
Matrix / MIMIServer

Matrix / MIMInetwork

7

Polyglotapp(Gatekeeper’s client adds 3rd party protocol
3 support alongside the legacy service)
iMessage Server

Fred’s device

Iona’s device
iMessage
Client●Fb Msgr.
ClientFb Msgr. ServerFred is a Facebook Messenger user.

Matrix
ClientiMsg.
Account➡ Let’s assume Facebook has added

Matrix/MIMI/etc alongside the existing FB
stackiMsg.
Bridge App
Matrix / MIMI
ServerMeta’sMatrix /MIMI Server

Matrix / MIMI
network

iMessage: client-side bridging using
client-side APIs
Facebook Messenger: polyglot app

8Polyglotapp(Gatekeeper’s client adds 3rd party protocol
3 support alongside the legacy service)Fred’s device

What itmeans forthegatekeeper(GK)● The GKs client adds support for a 3rd party protocol
as well as speaking to the legacy service● The 3rd party protocol can be an open protocol or
the RP’s protocol● Heavy implementation if GK implements several 3rdparty protocols

What itmeans fortherequesting
party (RP)● The RP needs to implement the protocol chosen by
the GK, unless it’s their own.
● The RP will have to do it for every GK they want tointeroperate with → xn eﬀort

What itmeans forthe users● RP’s users can seamlessly talk to GK users and viceversa
● RP’s users may either use their own Matrix ID or theGK may generate one automaticallyFb Msgr.
ClientFb Msgr. ServerMatrix
ClientMeta’sMatrix /MIMI ServerMatrix / MIMI
network9

4 Gatekeeper switches to open protocol
Fred’s device
Gemma’s device
Fb Msgr.
Client●Gemma is a Google Chat user.

Fb Msgr. ServerMatrix
ClientGoogle Chat
ClientGoogle’sMatrix / MIMI
Server=> Let’s assume Google Chat decides toswitch to talk Matrix/MIMI natively.
Meta’sMatrix /MIMI Server

Matrix / MIMI
network

Facebook Messenger: polyglot app
Google Chat: native Matrix/MIMI support

10

4 Gatekeeper switches to open protocol
Gemma’s device

What it means
for thegatekeeper(GK)● The GK speaks the 3rd party protocol entirely● The GK can interoperate with anyone implementing
the open protocol● More invasive change from an implementation
perspective, but more sustainable too and easier tomaintain.

What it means
for therequesting
party (RP)● The RP needs to implement the open protocolchosen by the GK● It will enable them to interoperate with anyone
using the chosen open protocol

What it means
for the users● RP’s users can seamlessly talk to GK users andvice versa

Google ChatClient

Google’sMatrix / MIMIServerMatrix / MIMInetwork

11

Interoperability is implementation agnostic
iMessage Server●●●

Walter is a WhatsApp user and doesn’t careabout interop.
Bob is a WhatsApp user and wants to talk topeople who are not on WhatsApp.
Charlie has a WhatsApp account but doesn’twant to use the WhatsApp app.

●

Martin is a Matrix user.

●

Iona is an iMessage user who wants to expose
herself to non-iMessage users, or use anotherapp to / user interface to communicate.

●●Fred is a Facebook Messenger user.

Fred’s device
Gemma’s device

Iona’s device
iMessageClient

Fb Msgr.
ClientFb Msgr. ServerMatrix
ClientiMsg.
Account

Martin’s device
Google’sMatrix / MIMI
ServeriMsg.
Bridge App
Matrix / MIMI
ServerBob’s device

Google Chat
ClientMeta’sMatrix /MIMI ServerCharlie’s device

WA Bridge
AppWA
Account

Gemma is a Google Chat user.
WhatsApp
ClientMatrix / MIMI
network

Matrix
ClientMatrix /MIMI Server

Matrix
ClientWA Bridge
AppWA
Account

WhatsApp Server
Walter’s device

WhatsApp: client-side bridging using
server-side APIs

WhatsApp
ClientiMessage: client-side bridging using
client-side APIs
Facebook Messenger: polyglot app
Google Chat: native Matrix/MIMI support

Pros & ConsPros

Cons

1 - Client-side bridging
using server-side APIs●

Minimal effort from GK: just need to document
their current API and represent remote users.

●

Traffic does 3 client↔server traversals (GK-app →GK-server → bridge-client -> RP-server)

Existing example: Matrix WhatsApp<->GChatdemo●Bridges can be supplied by anyone.

●GK users have to opt in by installing a separate
bridging app.

2 - Client-side bridging using
client-side APIs

●GK has to make their app expose a simple
client-side API that lets other apps send/recv
msgs etc.

●GK users have to opt in by installing a separate
bridging app.

●

OS vendor might need to get involved to define astandard ‘intent’ or API to let bridge apps talk toGK apps●

Traffic does 1 client↔server traversal (GK-app →bridge-client -> RP-server)●Bridges can be supplied by anyone.

3 - Polyglot app●

GK users can automatically speak to RPs without
installing a separate app!

●GK has to add an RP stack to their app alongside
their existing stack.

Existing example: iMessage’s support forSMS●No bridges; the bridge is effectively now within
the GK app.

●Risk of substandard RP implementation from GK
undermines DMA; users might end up using bridge
apps anyway.

4 - Gatekeeper switches to open
protocol●GK users can automatically speak to all RPs who
implement the open protocol●

GK’s investment in existing stack is lost.

Existing example: Reddit’s implementation ofMatrix●GK can build differentiating features on the open
protocol to add value, rather than relying onnetwork effects.

13User Discovery
Finding BobWe’ve focused on interoperability
rather than identity anddiscoverability, but here is a highlevel example of how it could work:●●

Walter is on WalterChat, an
existing gatekeeper○

E2EE messaging service○

identifies users using phone
numbers

Walter wants to start a 1-to-1
conversation with Bob○

Bob doesn’t use WalterChat○

Walter knows he is a keenuser of BobChat.
14

Thank you

15

Interoperability Implementation Options
Summary table
Implementation options

What it means for the gatekeeper (GK)

What it means for the requesting
party (RP)

What it means for the user

1 - Client-side bridging
using server-side APIs

● The GK needs to expose the server-side APIs
allowing the RP to develop a bridge● The GK needs a way to represent remote users● Simplest / quickest to implement, pragmatic but ugly

● The RP needs to source and advertise abridge● GK’s users can install the bridge to expose
themselves to the RP’s users● RP’s users can install the bridge to connect toGK’s users (need an account on the GK’snetwork)

2 - Client-side bridging using
client-side APIs

● The device’s operating system has to provide aninterface for the client-side APIs
● The GK keeps their app as it is, other than exposing
the client-side APIs allowing the RP to develop abridge● The GK needs a way to represent remote users● The RP needs to source and advertise abridge● GK’s users can install the bridge to expose
themselves to the RP’s users● RP’s users can install the bridge to connect toGK’s users (need an account on the GK’snetwork)

3 - Polyglot app● The GKs client adds support for a 3rd party protocol
as well as speaking to the legacy service● The 3rd party protocol can be an open protocol or
the RP’s protocol● Heavy implementation if GK implements several 3rdparty protocols● The RP needs to implement the protocolchosen by the GK, unless it’s their own.
● The RP will have to do it for every GK
they want to interoperate with → xn eﬀort● RP’s users can seamlessly talk to GK users
and vice versa● RP’s users may either use their own Matrix IDor the GK may generate one automatically● The GK speaks the 3rd party protocol entirely● The GK can interoperate with anyone implementing
the open protocol● More invasive change from an implementation
perspective, but more sustainable too and easier tomaintain.

● The RP needs to implement the open
protocol chosen by the GK● It will enable them to interoperate withanyone using the chosen open protocol● RP’s users can seamlessly talk to GK users
and vice versa

Existing example: Matrix
WhatsApp<->GChat demo

Existing example: iMessage’s
support for SMS

4 - Gatekeeper switches toopen protocol
Existing example: Reddit’s
implementation of Matrix

16