The Session Protocol: A new standard for decentralised private messaging

Session has come a long way since its public launch in January of 2020. Today, we’re announcing the next big step for our lean, mean encrypted messaging machine: a new encryption protocol, built from the ground up for decentralised secure messaging. But before we dive into that, let’s take a walk down memory lane and look at where we’ve been, where we are, and (most importantly) where we’re going.

What’s past is prologue

Back in 2018, the vision that would become Session was just a twinkle in our eye. We wanted to build something nobody had built before: a fully decentralised, end-to-end encrypted anonymous messaging platform running on a global network of user-operated nodes.

Simply put, we wanted to create a messenger that put the power back in users’ hands.

So we set out to build it.

Early builds of the app that would become Session were… a little rough around the edges, to say the least. But the bones were there — largely thanks to the  Signal codebase. Forking Signal’s well-established client and encryption protocol gave Session a great starting point. At the time, building on Signal’s foundations gave us exactly what we needed to get a headstart in the crowded and highly competitive messaging space.

Session makes a splash

After a year in early alpha and beta stages, Session made its public debut back in January 2020 — and we were amazed by the response. Obviously, we believed in what we were building, but as download counts skyrocketed and positive (and constructive!) reviews poured in, it became clear you believed in our vision too. It was hugely encouraging that so many people saw the very real need for a fully anonymous, decentralised encrypted messenger.

Invigorated by this deluge of support, and keeping both positive feedback and constructive criticism in mind, we began rethinking our aims for the project. It was clear that Session was fast outgrowing its roots as the little anonymous decentralised Signal fork that could, and users were requesting features that would make Session even more useful and competitive — features like multi-device support, voice and video calling, and more. We wanted to give users the features they needed in order for Session to fit into their lives and their workflows, but as we began adding more and more custom code on top of the Signal codebase, things started to get tricky.

Unexpected interactions, bugs, and other issues arose as we worked to implement these new features and integrate them with Session’s foundation of Signal code. So we began to consider how we could streamline Session, keeping everything that makes the app and platform unique while enabling us to build and integrate powerful new features with ease.

The refactor factor

One important part of this streamlining process was a refactor: restructuring Session’s code to make it more streamlined, without changing or removing any user-facing functionality. As Session has grown, we’ve ended up with messy Session-Signal overlaps and redundant code that introduced stability and reliability issues and made development harder than it needed to be.

Now, as it turned out, this refactor actually turned into a number of refactoring efforts, starting with our refactor of the Service Node communication code all the way back in April, and continuing with our partial refactors of the mobile and desktop clients, and other smaller refactors along the way. These refactors have made Session’s code much leaner, meaner, and easier to work with — particularly in the areas where our code overlapped with Signal’s.

At this point, we’d refactored a large chunk of Session’s client-side code. But there was still one area of the app we hadn’t streamlined.

Encrypt, decrypt, repeat

One of the parts of Session’s original, Signal-forked codebase that consistently introduced the most issues during our efforts to implement new features was the encryption protocol itself. The Signal protocol is the industry standard for a reason. It’s rock-solid, and it gave us guaranteed security while we built out the rest of Session on top. But while the Signal protocol is great for, well, Signal, building on it began to introduce challenges for the Session project. The reality is that while Signal is laser-focused on security, Session’s vision includes a focus on anonymity and decentralisation, too — and trying to shoehorn the Signal protocol into that vision was like forcing a square peg into a round hole. The Signal protocol wasn’t built with decentralisation in mind, for example.

It might be feasible for a huge organization like WhatsApp, backed by Facebook’s practically unlimited development resources, to cram the Signal protocol into their messenger. But it became clear to us that trying to build the crucial new features our users needed on top of the Signal protocol was making Session’s development less like running a race and more like trudging through mud. After spending years cozied up to the Signal codebase, it became clear to us that the best way forward for Session would be using its very own purpose-built protocol.

Introducing: the Session Protocol

We believe Session is the future of decentralised messaging — and to fully realise our vision, Session needs a streamlined, purpose-built protocol.

Today, we’re announcing exactly that: the Session Protocol. The Session Protocol is built from the ground up for anonymity and decentralisation. This new protocol streamlines Session’s design, enabling us to build and implement exciting new features — while ensuring your messages stay secret, safe, and secure.

We’ll be releasing a comprehensive technical writeup shortly that will outline the nuts and bolts around how we’ll be implementing this new protocol. In a nutshell, we’ll be rolling the Session Protocol out in stages to ensure backwards compatibility with older Session clients which still rely on the Signal protocol. More information on that rollout will be available soon.

The Session Protocol lays the groundwork for the future of Session — and we can’t wait to get started.