Let’s get Chatty! (updated August 30th, 2018)

• About
• Latest Posts

Purism

Beautiful, Secure, Privacy-Respecting Laptops, Tablets, PCs, and Phones

Latest posts by Purism (see all)

• PureOS Crimson Development Report: October 2024 - November 14, 2024
• PureOS Crimson Development Report: September 2024 - October 16, 2024
• Quantum Safe Communication with Purism - September 23, 2024

Today we provide a technical update and demonstration of SMS and—additionally—end-to-end encrypted XMPP messages on the chat application we’re developing, “Chatty”. But first, a bit of historical context…

The rise and fall of instant messengers

In today’s rapidly changing world, new proprietary products appear every fifteen minutes. Some of them attract quite a lot of users and survive in the market for a couple of years. However, someday they’ll disappear because other services become more attractive regarding functionality or for the simple reason that huge marketing campaigns have pushed them. In the social media world, we have seen MySpace sink into insignificance when people ran to Facebook. But there has been much more fluctuation in the messenger world during the past two decades. 20 years ago we used ICQ until AOL acquired it. Then for some time, MSN and Yahoo Messenger had their glory days. The former was discontinued in 2013, and Yahoo pulled the plug on their 20 year old service on July 17 this year.

Today WhatsApp and Facebook-Messenger are the trend. But as user habits change, like people today gravitating to social media services, it is likely that both services won’t be able to keep up and presumably have the same limited lifespan as their predecessors. Today, Facebook-Messenger users run over to the Instagram Messaging service and Telegram chips away users from WhatsApp, and so on.

Escape the walled gardens

Proprietary messaging services are mostly centralized, non-federated systems run by a single corporate provider. Since the protocols and/or the server software isn’t Free Software (where the source code is available), users cannot understand how their data is utilized. Although the service provider can’t always eavesdrop on communications when end to end encryption is applied, the service provider can see to who you talk to and at what time since they manage the accounts and buddy lists with all the related metadata in a single provider system.

The alternative to single provider systems is decentralized, federated structures that run a fully freedom-respecting software stack. Multiple servers relay information by a common protocol, allowing people that are registered at different service providers to communicate with each other. This type of conversation handling works mostly like email. Of course, one has to trust the service provider that manages the account then, but this data won’t be entirely handed over to the relay stations, though a certain amount of metadata has to be shared with the servers where buddies run their account.

There is, of course, the Matrix protocol which we love (we use it every day!) and are committed to bringing to the Librem 5. But we also wanted to offer some kind of E2E encrypted communication on “day one” (which Fractal—the native client application we’re hoping to use—doesn’t support yet), so while work is happening on Fractal on its own schedule, we are also offering an alternative based on XMPP.

XMPP (Extensible Messaging and Presence Protocol) is also such a federated system and well-defined standard. It was developed in 1999 by the Jabber community to provide instant messaging, multi-party chat, voice and video calls. Many free software implementations are available for XMPP chat.

• Anyone can run a XMPP server on their own, with Prosody for example.
• Getting started on the client side is pretty easy, as there are multitudes of client applications for all platforms (Pidgin, Gajim or Dino for Linux; Adium and Swift on macOS; Conversations on Android; ChatSecure on iOS)
• There are plenty of public XMPP servers to choose from (when you have picked an XMPP server from the list, you may want to check its security with IM Observatory. It makes some connections and performs a couple of tests to evaluate the client-to-server encryption and the server-to-server encryption).

SMS: old but gold

Today, most of us do online banking with SMS two-factor authentication. A lot of online services also make use of this method of authentication. SMS may be viewed as an antiquated technology, but the reality is that SMS plays a role in most modern technologies. A survey showed that SMS is the most effective way to reach users, with a 90 percent read rate in minutes. Why is that? Because if people get an SMS, they think it must be something important. Sending an SMS is thought of as being reliable. And frankly speaking, I also send SMS every now and then if I want to be sure that my message reaches its destination and is going to be read in time, even if I have reliable wifi.

“The rumors of my death have been greatly exaggerated”
— Mark Twain, sent from his BlackBerry

So, realistically, a phone like the Librem 5 still needs an application to handle SMS messages.

SMS will be implemented in our application codenamed “Chatty” (this working title wasn’t chosen by a long shot then), as a plugin for libpurple that provides an interface to ModemManager.

• The libpurple library supports many instant messaging protocols via plugins and allows the user to log into various services from just one application simultaneously. The messaging client Pidgin is the most widely known user of this library and libpurple was originally developed for it.
• Libpurple also gets the benefit of having this capability for any client allowing other software developers to create their own SMS client.

“While you’re there…”

At the very start, “Chatty” was merely meant to be the application to handle SMS for the Librem 5, due to our tight deadlines and limited resources.

Over time, when talking about messaging services in the team, discussions kept coming up that it would be nice to have SMS and E2EE IM taking place in just one application. And since we all feel inconvenienced when we have to remember which chat ecosystem to choose when we want to chat with a friend whom we haven’t texted with for a while, we thought the idea of having a single app accommodate a number of messaging protocols has a lot of merit, especially when libpurple provides extra protocols “cheaply”. With this, adding XMPP support “while we’re there” is fairly trivial.

Therefore, as a bonus feature, Chatty is going to support XMPP with OMEMO encryption as well as SMS on day one, instead of only SMS. Other protocols like Telegram may be added later if their features can be represented appropriately within the front-end. And, again, we’re not backing down on our commitment to provide Matrix for the Librem 5. Both XMPP and the Matrix protocol can provide End-to-End encryption. The fact that we’re providing XMPP as a feature is purely an additive process.

So, how is Chatty doing?

At the moment Chatty can perform some basic (and arguably most difficult task of) send and receive operations with SMS via ModemManager and a SIMCOM modem, as well as with XMPP/OMEMO messages via libpurple and the lurch plugin, like shown in this short demo video:

Currently, Chatty’s basic functionality is going to be expanded by writing functions for linking GTK+ objects with libpurple. These callback functions will be registered with the libpurple UI interface structs and signals so that the libpurple core can manage the conversations, the roster, and the user interface.

Libpurple conveniently provides the core functionality for IM applications in general, not just protocols per se. When a buddy is chosen from the roster panel, libpurple pulls the data related to the buddy ID, selects the plugin for the protocol type, establishes a connection to the buddy, and emits signals that trigger callback functions to set up the UI by loading the chat history and bringing up the chat screen.

There is some way to go to make Chatty a decent messaging app for the Librem 5. Here are some of the many things that will have to be done:

• Wrapping the SMS/ModemManager code in a libpurple plugin (The work on the plugin has started already. The interface to ModemManager works, and its output can be viewed in the Pidgin debug window.)
• Storing message histories in a database
• Creating a chat view with image rendering and lazy load capabilities
• Interfacing with the contacts database
• Designing screens for setting up libpurple accounts (for XMPP and those who may be added later)
• Implementing E2EE for files (pictures) into the lurch plugin
• Including trust management into lurch plus designing an appropriate UI

XMPP clients with OMEMO encryption haven’t been available for mobile devices until “Conversations” was released for Android in 2015, so it is an exciting mission to make XMPP messaging available on the Librem 5. And maybe other protocols will be introduced later via libpurple plugins.

Interesting reads

There are some myths out there regarding the performance of XMPP. This article sheds some light on it.

Daniel Gultsch wrote an excellent piece about the efforts that he and Andreas Straub spent on making OMEMO encryption broadly available for XMPP clients. While it took them more than two years, WhatsApp, for example, was able to roll out encryption overnight. But nothing could describe this dear-bought feature better than the conclusion in Daniel’s essay:

“…Enabling end-to-end encryption in a homogenous environment is easier than introducing it in a heterogenous one like Jabber… However, if something is hard to achieve there are two possible approaches: Either try your best and don’t give up, or put your head in the sand and create yet another walled garden that is no different from other proprietary solutions.”