Haskell in Production: SimpleX
Tags: haskell
Published: 2022-05-18 09:42:26

---
title: Haskell in Production: SimpleX
published: true
date: 2022-05-17 00:00:00 UTC
tags: haskell
canonical_url: https://serokell.io/blog/haskell-in-production-simplex
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e9g9mf3qg74waz0rae1a.png
---

In this edition of our [Haskell in Production](https://serokell.io/blog/haskell-in-production) series, I interview Evgeny Poberezkin. Evgeny is the creator of SimpleX – a decentralized messaging and application platform – and the founder of SimpleX Chat, a company that is one of the operators on the SimpleX network.

Read further to find out where and how SimpleX uses Haskell, why they chose it, and what was their experience compiling Haskell to mobile devices.

## Interview with Evgeny Poberezkin

### Could you tell us a little bit about SimpleX and your role there?

SimpleX is a new decentralized messaging and application platform that I’ve designed. I have also founded SimpleX Chat – a company that is one of the SimpleX network operators, same as Gmail is to email.

Unlike any other existing messaging platform, SimpleX has no identifiers assigned to the users – not even random numbers. This protects the privacy of those you’re communicating with, hiding it from SimpleX platform servers and from any observers.

SimpleX uses redundant, disposable message relay nodes to asynchronously pass messages via unidirectional (simplex) message queues, providing recipient and sender anonymity.

Unlike P2P networks, all messages are passed through one or several server nodes that do not even need to have persistence. In fact, our reference SMP server implementation uses in-memory message storage, persisting only the information about the queues. SimpleX provides better metadata protection than P2P designs, as no global participant identifiers are used to deliver messages, and avoids most problems of P2P networks.

Unlike federated networks, the server nodes do not have records of the users, do not communicate with each other and do not store messages after they are delivered to the recipients. There is no way to discover the full list of servers participating in the SimpleX network. This design avoids the problem of metadata visibility that all federated networks have and better protects from the network-wide attacks.

Only client devices have information about users, their contacts, and groups.

See the [SimpleX whitepaper](https://github.com/simplex-chat/simplexmq/blob/master/protocol/overview-tjr.md) for more information on platform objectives and technical design.

![Evgeny Poberezkin card](https://serokell.io/files/b4/b4mzjlwz.card-Evgeny_Poberezkin_(1).png)

### What’s the tech stack of SimpleX?

The servers and the core of all client applications (terminal, iOS, and Android) are programmed in Haskell. The UIs of the mobile apps are created using SwiftUI and Jetpack Compose frameworks for iOS and Android, respectively. To cross-compile Haskell to mobile platforms, we use Nix.

### How and why did you choose Haskell for this project?

At the end of 2020, I started implementing the SimpleX Messaging Protocol server in Go – I really disliked it, and what broke me was that there was nothing in the standard library to get dictionary keys… I hadn’t used Haskell before, but what I read was telling me that I should be able to develop a working model of the communication network and gradually evolve it into a working system, where components would become isolated processes, with minimal changes to code. I thought it was possible, but my Haskell knowledge was nowhere near enough, so I spent quite some time learning it and experimenting with protocol design at the same time, going quite deeply into various papers by Simon, Oleg, etc.

By October 2020, I decided that it was probably enough playing with Haskell – there was no end in sight to the depths of Haskell’s type system – so I just implemented the server in a week. Simon Marlow’s book on concurrent programming was particularly helpful. Several people told me then that I should do it in Rust, but the code base was growing, so we stuck with Haskell.

### Is there anything special in Haskell that makes it well-suited for making privacy-oriented applications?

I don’t think that Haskell is particularly well suited for privacy oriented applications – privacy depends on the system design much more than on the primitives you use, and you can use decent cryptographic libraries in any language.

I do think though that Haskell is exceptionally well suited for all highly concurrent communication applications, whether privacy focussed or not, because of several things:

1. green threads runtime, which allows to create millions of threads without worrying about managing system resources,
2. composable transactional memory (STM) to have strong consistency guarantees in highly concurrent scenarios,
3. parsing ecosystem that makes it very easy to implement custom communication protocols,
4. dependent types (well, almost), that allowed us to codify both protocol and UX invariants on the type level – we use them extensively.

Haskell dependent types is a separate big story – I wrote [three blog posts](http://www.poberezkin.com/tags/haskell.html) about it. Haskellers know that we don’t have them for real, but we can simulate them using singleton types and type families, which is good enough.

No other production-ready language has anything as advanced, not even Erlang, which some people believe is the best language for communication systems.

### Are there any awesome Haskell libraries that you found very useful while developing SimpleX and would like to feature?

STM that I mentioned is a library without which we could not have done it, and there were many others for networking and cryptography – network, tls, cryptonite, etc. – they are all very solid libraries.

### Are there any places where you think Haskell falls short as a programming language currently?

The worst part of Haskell is its handling of JSON encoding – the Aeson library that everybody uses is quite complex to understand and use effectively. I believe that the unintuitive handling of JSON is one of the primary reasons that slows down Haskell adoption. We were lucky that we didn’t need JSON for quite some time, we’ve only added it on the top level of the protocol stack that we are exposing to mobile apps and to any integrations.

Another short-coming was a cross-platform terminal IO with unicode support – it doesn’t really work out of the box. Possibly, it was resolved in GHC 9.x, but with 8.10 we had to use a semi-abandoned library “terminal” that provides unicode-compatible terminal IO that works on all platforms – our terminal app uses it.

### Could you describe your biggest challenge while building SimpleX and how you overcame it?

Bringing SimpleX to mobile devices was the biggest challenge so far – we had a lot of help from Moritz Angermann, one of the best Haskell engineers in the world, who has been very passionate about using Haskell on mobile for the last ten years, and who did a lot of work, both in general – like his contributions to GHC so it can be used to compile to aarch64 CPUs – and specifically to help our project to compile our Haskell implementation to both iOS and Android.

### Compiling Haskell to mobile devices is something that’s quite rare, especially with a project of this size. Could you talk more about your experience with doing that?

I should admit that most of it goes straight over my head, as it requires a deeper understanding of Nix, compilers, linkers, etc. than I have. I am slowly learning these things, but my main focus is on application development.

The only reason we were forced to solve this problem was that we had a relatively large and robust code base, and the alternative to compiling Haskell to mobile was re-writing it in any other language.

Every single software developer I spoke with suggested that I should re-write it in a language X, where X was their preferred language – C++, Rust, JavaScript, Dart, Swift, Kotlin, you name it. The problem with that approach is that all programming languages are equally terrible, and Haskell is no exception, so the best language is usually the one you have the most code written in.

If we had a bit more cash we probably would have re-written it all in Rust. But we didn’t, so this scarcity of resources together with Moritz’s passion for Haskell on mobile made it possible.

### As I understand, SimpleX is a fully open-source project. Do you have any plans of monetizing it?

SimpleX is indeed fully open-source – both server and client implementations.

We already have been lucky with donations from the users – we had about $9000 so far – at some point this year we will add an option to subscribe for using SimpleX, right from the app, to make it easier for people who want to support us. It won’t be mandatory, users will be able to use it for free, but this should create some revenue for us.

We are also planning commercial integrations with the platform and SDKs. This is a bit early to decide how exactly it would work commercially, but we are already working on one integration for the app with several hundred thousand users, and our current focus is on adoption and adding features for the end users.

### What’s in the pipeline for SimpleX – what are you currently working on?

We have just released SimpleX v2 that adds support for sending images and files and makes the process of establishing connection between the users more intuitive.

Another exciting thing that is coming soon is E2E-encrypted audio and video calls from the app – and it might work in such a way that the users of the mobile app will be able to call users who use our terminal app (and would use the browser for calls). As users already have a secure E2E-encrypted chat channel, we will use both as a signaling channel for WebRTC connection and as a way to negotiate a shared encryption key for the users – it will work completely transparently, users will just have to click the “call” button in the app.

### What tips would you give for developers that want to launch their own Haskell open-source project like SimpleX?

I’ve made an [improvised talk](https://www.poberezkin.com/posts/2019-07-10-talk-why-you-should-open-source-for-real.html) at a conference about why developers should invest their time into doing open source projects.

This is quite embarrassing to watch for me, still. The main point of the talk is that you should not do what you think will be needed or what people will pay for, but do something you really would want to do if you didn’t need money at all. Making good software is hard, it requires a lot of time, thinking and focus, even with relatively simple things, so unless you really care about the subject, you are unlikely to have the motivation to keep going and will just abandon it – like it has already happened with many promising open source projects. So it’s best to try to pick something you think you would want to work on for a long time…

### Where can people learn more about SimpleX?

The best place to read about SimpleX is our GitHub repository: [https://github.com/simplex-chat/simplex-chat](https://github.com/simplex-chat/simplex-chat). It repeats some of the things I’ve said above and more, and it also has the link to the SimpleX whitepaper.

* * *

Hope you enjoyed our interview with Evgeny!

To read more interviews with companies that use Haskell to solve real-world problems, head to our [interview](https://serokell.io/blog/interviews) section. Also, be sure to follow us on [Twitter](https://twitter.com/serokell) or subscribe to our mailing list (via form below) to get updates whenever we release new articles.