Activity Workshop
 

Murmeli - Development

Yes, you read that correctly, this is now development! The ideas have been bouncing around for half a decade now, and I was beginning to wonder whether it would ever reach the coding stage, because the problems seemed too enormous and complex to solve. Yet here we are, and work has now started on the foundations of this new platform.

As you've seen, the working title is now Murmeli rather than Murmur. But many of the ideas remain the same. It's just become a little clearer how to actually implement some of these ideas now.

Building blocks

For a long time, the thinking was to either contribute to, or extend or adapt, or to build on top of, one of the existing platforms such as OneSwarm or RetroShare. But these codebases are huge, and fluid, and so the direction has changed. Work has started using a combination of building blocks, which should be available on all the platforms we need to support.

For Debian, the required packages are python3, python3-pyqt4, tor, python3-pysocks, gnupg, python3-gnupg, python3-pymongo, mongodb-server, python3-tempita and probably also python3-pil (all from Debian stable).

For Windows, you'll have to find, download and install all of these dependencies yourself - they come in a mix of .exe and .msi installers, .tar.gz python tarballs and .egg python eggs. In particular, the tor installer is quite difficult to find, as for Murmeli you only need the tor exe and not the whole browser bundle.

Progress

It's still at a relatively early stage. But we now have a Qt GUI, with some basic functionality, including display of html pages, basic pageflow and connection to the mongo database, GPG and tor. And we have a startup wizard, which can guide the user to set everything up, checking dependencies and specifying paths for the database, the keyring and the tor cache, and the various executables such as tor and mongod.

For an idea of the current development status, see the new youtube video demonstrating the process of setup, establishing contact, verifying key fingerprints and sending the first message.

These screenshots show the flow through the startup wizard, where the language is selectable on the first panel. Subsequent panels lead through the steps in turn, if necessary setting up the database, generating an asymmetric keypair for the encryption, and starting one's own profile.

startup wizard

Introduction page

startup wizard

Checking dependencies

startup wizard

Defining paths

startup wizard

Starting services

startup wizard

Key generation

startup wizard

Key selection

startup wizard

Finished

Both tor and mongod are now started, and the main application can be launched. The main bit of the window is a QWebView from Qt, giving the flexibility of HTML display for showing messages, profiles and so on. In the Settings panel you can change the language, currently English and German are supported.

main window

Basic GUI with main menu items

window icon

Icon

profile page

Profile page from the database
with avatar icon

edit own details

Options to edit
one's own details

add new contact

Adding a new contact
using their id

show incoming requests

Listing of incoming
contact request messages

check key fingerprints

Instructions for checking
key fingerprints (updated)

incoming message

Incoming regular message

settings page

Settings page
for changing language

new message

Composing a
new message

friend graph

Drawing of friend graph


These screenshots show a selection of the currently working functionality, including showing a contact list, requesting a new contact, checking fingerprints and showing messages. These are the functions which Murmeli is now able to do:

Excitingly, Murmeli has now not only sent its first ever message successfully through tor, but also sent its first ever encrypted message successfully through tor! Both databases have now been updated with each other's details, and the public keys have been added to each other's keyrings, so the basic connections have been established. We've also now got the exchange of profile information, and for the first time also blind relaying between trusted friends. And the best thing about this is that apart from the initial key generation during the startup wizard, there has been no mention of encryption in the Murmeli GUI. That means, no need to enter passwords (there aren't any), no need to choose encryption schemes or strengths (there is none of the confusion about S/MIME or GnuPG or inline PGP you get with encrypted email), no need to choose whether you want things to be sent encrypted or not, it just does it.

Ok, since the addition of the key confirmation then there is at least some extra complexity and some mention of the care required to verify the secure connection, but hopefully the codeword scheme is a little bit friendlier than reading out long alphanumeric key fingerprints to each other.

As shown in the last of these screenshots, the code from Brainstorm can be used to display graphically your network of friends. If your friends allow it, you can see who your friends' friends are, and connect those up too. And of course the graph wobbles in a pleasing way. It would be nice to be able to refer contacts to each other from this graph too.

Don't take too much notice of the exact presentation of these pages just yet - work is concentrating on functionality rather than visual design. All the pages are built with tempita templates, html and css so the layout can easily be changed and quite possibly made more dynamic with jQuery, once everything is working properly. Eventually it may be possible to customise the display with different themes, for example.

Not all of the current development code is ready for publishing yet, but the basics can now be found on Github. At the time of writing, this includes the startup wizard and basic configuration, the main window with toolbar and page server, and a basic settings page for changing the language and the privacy settings. So that means no messaging yet, but more code will follow soon.

Update August 2016: Most of the testing has been done between three computers on the same network, so it was an exciting test to take one of the machines over 100 kilometres away and see if the queued messages could still be properly sent. (Otherwise there's still the lingering suspicion that it wouldn't work properly out over the real internet and through routers.) And sure enough, the status notifications, info request, info response, regular message and relayed message all got sent properly through tor over the internet, and were correctly received.

Can Johnny encrypt now?

There have been many reports over the last two decades about how difficult PGP is, how unfriendly encrypted email is, and how much difficulty even experienced computer users have with the concepts of keys, keyrings and encryption schemes. All too often, users get so frustrated trying to set things up that they either fail or give up. And even then, it is all too easy to accidentally send something unencrypted or wrongly encrypted. Hopefully Murmeli's process will prove to be much simpler, much more user-friendly, and much more difficult to incorrectly use.

With Murmeli, you don't choose how to import public keys, you don't choose which keys to encrypt with, and you never choose whether to encrypt things or not. There still remains the question about how to satisfy the user that things really are being sent encrypted, but the aim is to keep that as hidden as possible. Perhaps an additional log window (which only the really curious would open!) could show the actual bytes being sent and received - which would of course make no sense to anybody apart from the unencrypted headers.

Murmeli ids

As already explained, Murmeli uses Tor's so-called "hidden services" (now called "onion services") to communicate between clients. In order to do this, tor generates an identifier for the service to publish, and this becomes your Murmeli id which you can give to your friends. Currently these ids are always 16-character, alphanumeric strings (like "06zyyt0xf0mt7gw8"), as determined by the tor protocol. Therefore, as it stands, if I wanted to give you my Murmeli id over the phone, the id is short enough that I could read it out and you could type it in, without too much inconvenience.

However, tor development doesn't stand still, and there are currently proposals in the works to change this to make all the ids longer (presumably to expand the id space and make it possible to publish more such services without collisions, and make deliberate collisions more difficult). Makes sense. Except that means the ids may be in future 52 characters long instead of 16, and that would make it really awkward to exchange ids except by copy-pasting. It would also mean changes to Murmeli's assumptions about id length, of course, and raises the questions about whether the two id formats will operate concurrently or whether all the current 16-character ids will become invalid at some point. We'll keep an eye on this.