In this guest post, William Dudley, Head of Mobile Innovations & Evangelism at Sinch examines how new EU legislation might have an impact on the future of interoperability between messaging providers, and explores what it could mean for the wider industry.
Over twenty years ago, I and a handful of others launched SMS interoperability to overcome mobile operators’ walled messaging gardens that existed across the various network technologies (GSM, TDMA, CDMA, and iDEN). We were quite successful as this opened SMS as a ubiquitous messaging medium, exceeding all expectations.
Today, SMS is still the most ubiquitous messaging channel on earth and is still going strong, despite what many say. The worries that SMS is not end-to-end encrypted is completely overblow and it is still heavily used around the world – not only for Person-to-Person, but also for businesses to reach consumers.
Now the European Union recently announced a rule in the Digital Markets Act (DMA) to require messaging app developers to enable their apps to interoperate – that is, to make them work together. For example, if I’m a WhatsApp user, my message might be received by an iMessage user, if that user does not use WhatsApp. Additionally, if I’m an Android user with RCS, my message could be received by a Telegram user or even an iMessage user. There could be endless combinations.
There’s been several articles written in the past few days – notably from The Verge:
- New EU law could require iMessage and WhatsApp to work with other, smaller platforms
- New EU law could spark gold rush of iMessage alternatives
Furthermore the EU Press Released noted: “EU lawmakers agreed that the largest messaging services (such as WhatsApp, Facebook Messenger or iMessage) will have to open up and interoperate with smaller messaging platforms, if they so request. Users of small or big platforms would then be able to exchange messages, send files or make video calls across messaging apps, thus giving them more choice.”
That’s a big lift!
So how would this work in principle? Given my background in messaging interoperability, I would be inclined to create an extension to the SMS/MMS (and to an extent: RCS) hubbing ecosystem that we have today. In fact, most of the non-SMS/MMS messaging apps support some or all rich messaging concepts that include discrete rich media: images, audio clips, video clips; rich cards (combinations of rich media plus text plus action buttons), as well as carousels of rich cards, and discrete action buttons. Of course, most also support video and audio calls – and these two will need to be relayed between services.
Let’s look at a few capabilities that would have to be agreed upon:
We would need a common protocol and one that could maintain encryption of the content.
While I certainly see what the framers of DMA were after with a mandate of messaging interoperability, as noted, there are lots of caveats. What if one of the parties is outside of the EU? Would the DMA mandates apply there? With GDPR, companies all over the world are supporting those mandates, should they happen to engage with EU users.“
In the SMS world, we typically use Short Message Peer-to-Peer (SMPP) for messaging between operators through a messaging hub. In the legacy GSM world, SS7 protocol MAP (Mobile Application Part) is used. MMS used a protocol called MM4 for P2P (but MM7 or REST for business messaging). But in recent years, some messaging hub providers also support a nice REST interface for P2P, between the service and the messaging hub.
The great benefit of one or more messaging hubs is the ability to support multiple protocols. Connect once, reach many. And really, that’s what we’re talking about with this new DMA proposal. Instead of multiple mobile operators, our hub would be connected to multiple message servers.
One protocol: XMPP might just be the ticket to help provide multi-messaging app interoperability. For one, Meta (WhatsApp and Facebook Messenger use it). Apple also uses it, as do many others. That said, not all use it for messaging, but some do. But, more realistically, each messaging app will likely offer up their own protocol or variation of some standard. Certainly, open standards would be preferable. Another tick for a messaging hub to make this happen. The messaging hub would be able to support each service’s preferred protocol, then routing onto the next service, transferring encrypted content to the destination service.
In some cases, like RCS, rich content is resolved by the destination messaging app – the content is not physically sent to the destination. Instead, a URL reference is sent, pointing to the content stored by the originator service. An interoperability would need the ability to determine how the destination service resolves rich content and how it could access it. We would also need to understand how the destination service would be able to decrypt all of the encrypted content that was sent to it.
Might we have to live with the fact that cross-messaging service content is not encrypted end-to-end? That would certainly bode well for those encrypted services like iMessage, WhatsApp, Signal, Telegram and others to use to stay within their gardens: Within the walled gardens, traffic is encrypted; outside the walled gardens, maybe not. Indeed, both WhatsApp and Apple as well as others have cited the inability to ensure end-to-end encryption across services, noting that DMA could weaken security and privacy across Europe (outlined in the 2nd cited Verge article, above).
Finally, a messaging Interoperability hub might be able to provide a unified messaging API and protocol that the messaging services themselves could use to deliver messages to other services. That may or may not support end-to-end encryption across services, but it would definitely be required to manage access to rich content whether through reference or some other means.
We would need a common method to address users
For many, but not all the messaging services, the user’s phone number serves as the unique identifier that can be leveraged. Certainly, a SIP URI or some other identifier could also be used, but it is probably easier to leverage the phone number—even if it is an alternative phone number for that service vs. the user’s mobile carrier phone number.
Many messaging services without phone numbers can support using a phone number if necessary. For example, how will an iMessage user send a message to a user on Facebook Messenger, who is running on a desktop? For interoperability to truly work, some messaging apps will have to be open to modifications to help cross-service addressing.
Rules for users with multiple messaging apps
If you are like me, I have several messaging apps installed on my phone. If you send me a WhatsApp message, I will receive it in WhatsApp, even though 95% of my texts originate and terminate on iMessage (which interoperates with SMS/MMS). But if a Signal user sends me a text, and Signal was part of the messaging interoperability ecosystem, then Signal should recognize that I am not a Signal user but am being addressed by a phone number. In that case, the message should come to my default messaging app (in my case, iMessage). If I respond, then one might expect my message to return to Signal. But since Signal uses phone numbers, that message might return to the originator on their default, carrier-based messaging app?
Like we do with multiple browsers on our devices today, whereby we select a default browser, we could select a default messaging app for our device. Android does that today. In a world where non-carrier messaging apps interoperate, that Android setting could be extended to support such apps. The feature would have to be added to iOS.
Ideally, conversations across different services should continue between the two services as the initial message and not switch to a different message app or service.
Fallback messaging
Despite all the protocols and all, there should be a method to deliver at least text and possibly some rich messages. The default choice would seem to be SMS/MMS – much in the same way RCS can fall back to SMS/MMS today.
For example, if a small messaging service wishes to interoperate with WhatsApp, the messaging hub may have to transcode down the messaging content to a more basic SMS and/or MMS message to reach the small messaging service.
Of course, there are many who only use SMS / MMS. That service too, will need to interoperate with the non-operator messaging services as well. If we as an industry are going to do this, SMS/MMS should be in the mix.
Fallback options should be available to support any messaging service that has minimum capabilities. SMS would seem to be the best, or at least the easiest choice. One might also consider RCS, as an open standard (albeit heavily promoted in the Google world) as a fallback messaging choice.
Additional Thoughts
While I certainly see what the framers of DMA were after with a mandate of messaging interoperability, as noted, there are lots of caveats. What if one of the parties is outside of the EU? Would the DMA mandates apply there? With GDPR, companies all over the world are supporting those mandates, should they happen to engage with EU users. The same will likely apply to messaging interoperability. And why not? If our industry will build such a messaging infrastructure to support the EU DMA, we’ll more than likely want it to apply to the rest of the world too.
A side-effect of this, of course, is that we could finally see Apple iMessage support RCS, at least for P2P; however, we’ve all really wanted this for business texting, which is where RCS really shines.
Despite supporting interoperability for P2P messaging, I suspect this won’t completely open the walled gardens of the big messaging apps. They will find ways to differentiate themselves. Today, many of us in the messaging world are seeing great innovations coming from these providers as they expand to enable businesses and brands to engage with consumers through their apps. I doubt that this engagement model will not change. DMA is really targeted to P2P messaging.
The final agreement has not yet been approved; however, besides all of the above, there are few concerning developments. There will be staggered deadlines to support a certain level of interoperability:
- 3 months to make cross-service messaging interoperable
- 2 years for group texts
- 3 or 4 years for video / audio calls.
However, I’m not aware that these are the final rules. This is once a smaller messaging provider requests interoperability with one of the bigger messaging services (or “gatekeepers” as the DMA calls them). Hopefully, there will be a period of time from once the law is signed until it actually goes into effect to allow the industry to agree on how this interoperability will be implemented.
My hope is that the bigger messaging apps can work with some the established P2P messaging hub providers to enable initial connectivity and some best practices, so that we would be ready to meet the requests. The interconnections should also leverage a secure global network, such as the global IPX network, vs. the general Internet. This will help security as well.
If this does come to fruition, there will be flurry of interconnections during the first few years, followed by a slowdown once everyone interoperates. After that point, only newer messaging entrants will wish to connect can be managed. Of course, with staggered launches for certain types of services, once messaging is figured out, there is still voice and video calls – which may actually be easier in today’s IP voice world.
I’ve not read anything regarding when this goes into law, but if/when it does, it’s going to be a lot of complex work, coordination and some good competition to make it all happen. Like the SMS and voice world, there are not single hubs, but many and they all interconnect or peer, so that one’s customers can reach another’s customers. That is the nature of interoperable communications. Just when you thought messaging could become a bit mundane, here we go again!
This post originally appeared on the Author’s personal blog – Mobility , Messaging and More and is republished here with kind permission
