Murmeli introduction

As described earlier, Murmeli is a decentral encrypted messaging system which is currently under development. If you have comments or suggestions, please send them in by email or using github. If all goes well, it will at some point be possible to submit comments using Murmeli - once the parrot has been set up.


The idea is to make it possible to exchange information and messages with your friends, without any company being in control of your data. For each message, you should be able to determine exactly who should be able to read it, from one single contact, to a selection of contacts or possibly groups of contacts.

Apart from the sender and the recipient of each message, noone else can understand the contents, even if they're acting as a (trusted) relay, because only the recipient has the key to decrypt what was written.

How it would work

A simple diagram to visualize the connections is shown below. The Facebook / WhatsApp / Twitter / Instagram / GooglePlus model is shown on the left, where the corporation (who is interested only in profit) owns, controls and monetises the data, and allows access to various people including your friends (and well-paying advertisers). Murmeli's proposed model is shown in the centre, where the users contact each other directly, and pass information in encrypted form to each other as they wish. For each message, nobody except the sender and the intended recipient can understand what is being said, and it's not even obvious who is sending something to whom.

Diagram to illustrate connections and data ownership

On the right of this diagram is another model, using a server for each user. Each user is then responsible for the maintenance of their own personal server, and the servers exchange information with each other. This alternative model would give benefits of continuous connectivity between servers and access from multiple clients, but gives each user a significant burden of obtaining, setting up and running their own additional server. This is the chosen model for Diaspora and Appleseed, among other networks. However, as we'll see, Murmeli will work fully peer-to-peer and won't require extra servers.

How it will work

Murmeli plans to take peer-to-peer messaging a little further, to make a so-called "darknet" (see wikipedia), and more specifically a "friend-to-friend network" (F2F rather than P2P). However, unlike many of the current darknets where the focus is on finding and sharing files, without caring too much where or who they come from, Murmeli's focus will instead be on requesting any and all new information from known and trusted friends. Anonymity isn't a goal at all, quite the opposite. Messages will be rejected unless they were demonstrably sent from a known and trusted friend (proved by digital signing).

So what happens if I want to send a message to a friend who isn't online right now? That's ok, I can send the message to any of my other friends who are online now and ask them to pass it on. Then when my intended recipient comes online, and I've gone, they can get the message from whoever is still online now. If I specify a maximum forwarding limit of 2 hops, then the message needn't traverse the whole network, just those with an indirect connection to me.

And what's to stop my other friends reading this particular message if they act as a trusted relay? Encryption. Each user of the program has a public key (which is public, given to everybody) and a private key, which they keep secret. So if I want to send a message to George, I take my message and encrypt it with George's public key. I send the message to Paul, but he can't read it because he can't decrypt it. Only when Paul forwards the message to George can George then use his private key to decrypt the message and read it. Paul can then delete his copy of the message of course.

In fact, Paul doesn't even need to know that I'm writing to George. Paul knows that the message is from me, because it's signed by me and he can verify that it's from someone he knows and trusts. But Paul can't decrypt the message, so the message can't be for Paul. Paul doesn't know who it's for, but can send it to everybody in his friends list (with a flag saying not to forward it any further), and just hope that somebody can decode it. Obviously this isn't an optimal use of bandwidth but the extra overhead should be negligible.

If enough of this is transparent, it should be as easy to use as email, and all I see is that I've sent a message to George and all he sees is that he receives a message from me. Nobody else needs to be informed that messages are being exchanged because they're not readable by them. Even the encryption can be completely transparent to make it as easy as possible.

Robot relays

An extension of this blind message relaying idea is to install some kind of "personal relay" on a permanent server. This would be hopefully lightweight and low-maintenance, and would just sit there, holding the public keys of you and your friends. It wouldn't know any private keys though, so it would only be able to store and relay encrypted messages blindly. For Murmeli clients which are only occasionally online, this would provide a useful mechanism for reducing latency and improving redundancy. It wouldn't be a single point of failure though, as to you it's just another optional relay possibility, only used if the direct path fails. If the robot isn't found, you've still got your other friends acting as relays too. If it gets raided, it only contains encrypted messages anyway so only the contact list is compromised, no messages and no keys.

The prototype Murmeli code is already running on a Raspberry Pi zero W, which provides a very low-cost, low-power option for this personal relay idea. In fact this particular Pi is a Scrollbot with an LED matrix to show the status and a cheerful orange robot head to emphasize the robot theme.


Introduction // Development // Beschreibung // Threats // Questions & answers // Message types // Message sequences // Robot setup