Yes, development is ongoing. 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.
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.
mongodb together with pymongo, but instead we're now going to use a simple file-based solution using python's native structures. Messages will be stored in unencrypted form (cleartext) inside this database, but if you want to, you can place the database in an encrypted partition.For Debian, the required packages for the base system (without gui) are python3, tor, python3-socks, gnupg, python3-gnupg and python3-pil (all from Debian stable). For the gui you'll also need python3-pyqt5, python3-pyqt5.qtwebengine and python3-tempita. To run a robot you don't need those three, or Qt, but if you want the Scrollbot functionality on your robot then you will need scrollphathd from pimoroni. If you've got a Raspberry Pi which isn't a Scrollbot, then you may need to manually remove the package python3-scrollphathd if it was installed automatically.
The robots (and parrots) probably shouldn't require python3-pil but at the moment it's required.
Most of the unit tests will run on any platform, but of course the ones requiring Qt or Tempita won't run on the robot, and the ones requiring LEDs won't run on the PC.
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.
The fundamentals are all working now. We have a Qt GUI, able to show html pages with css, javascript and jquery, and we have connection to the database, GPG and tor. We also have a separate startup wizard, which can guide the user to set everything up, checking dependencies and specifying paths for the local database and the various executables such as tor and gpg.
For an idea of the current development status, see the new (silent) demonstration videos on youtube:
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.
Introduction page
Checking dependencies
Defining paths
Starting services
Key generation
Key selection
Finished
The required services are now started, and the main application can be launched. Then we come to the main window shown in the screnshots below. The main bit of the Murmeli window is a QWebView from Qt (now called QWebEngineView), giving the flexibility of HTML display for showing messages, profiles and so on. In the Settings panel you can change the language, currently just English and German are supported.
Basic GUI with main menu items
Icon
Profile page from the database
with avatar icon
Options to edit
one's own details
Adding a new contact
using their id
Listing of incoming
contact request messages
Instructions for checking
key fingerprints
Incoming regular message
Settings page
for changing language
Composing a
new message
A tree of
message replies
Drawing of friend graph
Send and receive statistics
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 one 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.
The last photo shows an example of send and receive statistics displayed on a Scrollbot. The idea is that one trace is shown with bright dots rising from the bottom of the display, and the other trace has half-brightness with the zero value at the top of the screen. So one could be number of messages sent per minute and one the number received, with the screen showing each of the last fourteen minutes. This is just one suggestion so far.
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 (and a little jquery) so the layout can easily be changed once everything is working properly. Eventually it may be possible to customise the display with different themes, for example.
The current development code can now be found on Github. Suggestions, forks, patches and pull requests are welcome.
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.
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. Previously these ids were always 16-character, alphanumeric strings (like "06zyyt0xf0mt7gw8"), as determined by the tor protocol. Therefore, with such a length of id, 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 with recent developments in tor these Ids were all made 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 that with a current version of the tor client, the ids generated are now 56 characters long instead of 16, and that could make it really awkward to exchange ids except by copy-pasting. A current Murmeli with a 56-character id can still communicate with a 16-character id, but crucially not the other way round (the older client complains about the long id having an invalid length). So for Murmeli purposes they're not compatible.
This was a while ago and not really relevant any more - suffice it to say, development started using MongoDb as the local database, but then later for various reasons this was replaced with a python solution. It could be that in the future we decide to use a different database solution (there could be a few to choose from) but now we have the components separated in a much cleaner way, this replacement should be more straightforward.
Murmeli was originally using Qt4 and PyQt4, both on the desktop and on the Raspberry Pi. Then the migration was done to Qt5 and PyQt5, with the WebEngine based on Chromium, rather than Webkit. Unfortunately the WebEngine modules aren't available for Raspbian, so now Murmeli uses a gui-less option without Qt for robot relays, and a Gui option with Qt5 for the desktops. In this way at least headless robots (and LED robots!, and Parrots) can run on the Pi. Tests are ongoing with a Raspberry Pi 1 and a Raspberry Pi Zero W (in the form of a Pimoroni Scrollbot).
A separate issue is raised by Qt's newly-announced licensing changes. For newer versions of Qt, users won't be able to download the Qt binaries without registering for a Qt account, making it much more awkward to start using Murmeli. This is not likely to affect Linux users who will probably continue to get their Qt packages from the linux repositories as before, but it will significantly impact the installation on Windows and OSX. They're also apparently stopping support of their LTS releases for open source customers, but that's less of an issue if you don't mind updating to a non-LTS branch. Migration from Qt 5 to Qt 6 could be painful, hopefully not as painful as the migration from 4 to 5, but still there's effort there. Which raises the issue of whether Qt is worth the pain for the benefit it brings - the option of making Murmeli a purely web application running in your existing browser has been raised several times before, and maybe it's worth considering again. As long as the connections to the local web server can be reliably restricted to the genuine application and it's not open to other, unauthorised clients, then this could be a way to cut out Qt completely and therefore also allow a gui to run on the Raspberry Pi once again, as it did with Qt 4.
There is now a separate, dedicated page describing the robot setup procedure step by step. This can be a regular Pi, a little Pi Zero, or even a Scrollbot with LEDs.
For anyone curious, no Pimoroni are not sponsoring or supporting this project in any way, and did not provide the hardware, nor does the ActivityWorkshop receive any compensation for promoting the Scrollbot. It's just a really good fit for the Murmeli robot.