Messaging: From Apps to Architecture

When someone talks about messaging, the first thing that comes to mind is an app. 

It might be WhatsApp or Weibo, Facebook Messenger or Signal, iMessage or good-old SMS. Or maybe it’s Telegram, Viber, or - as highlighted by the chart below - something entirely different. A lot of messaging apps have deep adoption in national networks or among specific groups.

The point is, that most people experience messaging through an app. And, until recently, apps were what defined the messaging market. 

Now, it seems, all of that is about to change.

Let’s take one, big step back. The biggest challenge in messaging, bar none, is balancing the adoption of a technical standard with the competitive ownership interests of companies. For those who were around pre-mobile Internet, the original battle over messaging standards was rooted in mobile phone protocols - CDMA vs. GSM. CDMA was the United States’ standalone approach, and it (thankfully) gave way to the GSM standard, which is how most mobile networks have handled and exchanged data for a very long time. 

Messaging Systems.png

That’s important, because pre-smartphone adoption and pre-mobile Internet, messaging was primarily done over Short Messaging Service (SMS). SMS (and, later MMS), were designed as ways to make use of the unused gaps in spectrum - sending messages and files between phone calls. And so, almost by accident, the world’s messaging was standardized as part of mobile infrastructure adoption. That also meant that SMS revenue was offered through mobile infrastructure providers, as opposed to software providers. That also meant that messaging revenue is distributed geographically - as opposed to being centralized through an advertising or software service. 

Enter the smartphone. Among the many ways that smartphones have changed communication, they also introduced a new gatekeeper: the operating system. Operating systems are the software that comes pre-bundled on a phone and, pre-smartphones, they were mostly an afterthought. As smartphones came to dominate wealthy markets, there was also a push to standardize operating systems - and while there are still a range of options, including Apple’s iOS, Google’s ‘open source’ Android operating system has roundly won the global market. Android, like any scaled, open source product isn’t exactly one thing - a number of operators like Samsung and, soon, Huawei, implement a modified version of the Android system. 

Operating systems do things like set permissions for developers, determining what things a piece of software can and can’t do on a phone. Apple’s iOS, for example, famously does not allow developers to access SMS - meaning that any messaging has to be done by an application, “over the top (OTT)” - which means using Internet signal. Apple did this when they rolled out iMessage - their own OTT application that automatically routes messages between iPhones through an encrypted Internet service. In fact, all of the mobile messaging apps mentioned above are OTT applications and, basically, perform a similar service to what iMessage does - except, of course, using their own, proprietary standards. 

One messaging app - Signal - however, has been built on an open source protocol designed to deliver a specific feature - end-to-end encryption (e2e) - that has also been adopted by other messaging players including, notably, WhatsApp. Signal, WhatsApp, and a number of other messaging apps increasingly include approaches to e2e, but they’re all managed differently, based on the company and, critically, business model.

Now that we’re all caught up. 

This week, Google announced that Rich Communication Services (RCS), one of its less-loved messaging protocols, would also be adopting the Signal protocol and - and this is the important part - will be installed by default across Android users. In other words, Google will be rolling out the functionality that lies at the core of most messaging apps, as a default in the world’s most used operating system. They are doing ALMOST the same thing that Apple did in rolling out iMessage - with one, critical, difference: hosting.

The difference between using a standard and running an application company - between building Signal the protocol and administering Signal the app - is whether, how, and where data is hosted.

The difference between using a standard and running an application company - between building Signal the protocol and administering Signal the app - is whether, how, and where data is hosted. And we’re already starting to see that the core functions of messaging apps aren’t, in and of themselves, particularly complicated to build - the challenge has always been how to get to scale and serve the needs of a diverse range of users. As the marginal costs of building and, crucially, standardizing secure OTT messaging fall - we’re trends move away from scale.  

Now, as digital threats are becoming easier to understand, groups are starting to redesign and deploy messaging applications that fit their particular needs - whether that’s local hosting for data law compliance, support that works offline and/or in unstable environments, or bounding professional messaging networks for secure communications. In other words, we’re seeing the messaging market move back toward open standards, administered through app architectures - but less dependent on app companies. 

The transition from standards to apps to standards has increased the quality of the ecosystem and, importantly, makes it easier for users to run systems designed for their context. It won’t, of course, eliminate the opportunities for exploitation - even e2e apps can create extremely valuable metadata - but it is an important transition in messaging. 

And, as goes messaging, goes much of the digital utilities and public goods market. It may be that clear, locally run practice that appeals to global standards, isn’t just for political governance. And in the meantime, it will be exciting to continue helping organizations explore the messaging apps and architectures that provide safety, stability, and service in uncertain contexts.