Tomdroid - a free, roaming, distributed, secure, personal notes management

Posted by Jedd on 2014-01-07

Note

I subsequently – 2017-ish I think – moved away to Google Keep, as Tomdroid had a few limitations, and the occasional bug.

Google Keep's not ideal, but I can easily share notes, they're accessible offline, and have sufficient editing features to be usable without bloaty

Evernote has been annoying me for a while now. It feels a bit flaky, and it turns out it is more than a bit flaky. They don't make it easy for me to do my own (automated) backups. I'm not entirely convinced of their security or privacy arrangements. There's a stack of features I don't need (and which sometimes make it harder to access the functionality that I do need). The Android client interface is frequently frustrating, even on a 5" screen. Finally, as a Debian GNU/Linux user, I'm treated as a something less than a third rate citizen, left to rely upon the good work of volunteers like Randy Baumgarte if I want to use Evernote from my desktop.

Android disparagement
The Evernote Android client /

They give you the choice between two operating sytems that you neither use or like.

They could at least offer an 'Other' button.

And we'll try to ignore the type disparity (software (Windows) vs hardware Mac)).

Anyway, none of these things are compelling reason to continue to use the service, let alone become a paid-up customer.

Further, in recent weeks there's been yet another spate of hand-wringing and navel-gazing amongst the tech crowd about the quality of Evernote after Jason Kincaid's post, followed by Phil Libin (CEO of Evernote) writing a heartfelt response that, whilst laudable for its candidness, and optimistic in their self-assessment, essentially conceded that they have some non-trivial reliability issues.

So I finally got around to looking at the state of play for free alternatives, and then setting one up.

My requirements

If your requirements aren't vaguely similar, then this page isn't going to be very helpful.

But if you do have similar, basically quite modest requirements, then you're in luck. What I've set up is (so far) a good free substitute for Evernote that you can use from your Android phone, access from your desktop, and configure regular & frequent backups to suit your particular level of paranoia.

Features I wanted:

  • A back-end (server) that I can run on my own VM or VPS
  • Android client with a simple, efficient, and non-frustrating text editor
  • Access to my notes from my desktop environment -- a web client would be acceptable

Features I didn't care (much) about:

  • A native desktop client (this may be nice, but it's not a show-stopper)
  • Sharing notes with other people (though this is likely to change)
  • Capturing images, audio, video, or doing OCR on ingest
  • Tagging or categorising notes

I should point out that my disinterest in a native client might imply that I can't target that same complaint about Evernote, as Evernote also offers a web interface. It's more the fact that Evernote specifically do provide a Microsoft Windows and an Apple OSX native client, but just can't be arsed offering one for GNU/Linux. It shows disdain, but, worse, may indicate a lack of design foresight and/or massive code splitting going on inside the company. In the same way I'm wary of developers that can recite to you the entire set of Java standard libraries yet are not able to get their head around the difference between its and it's, I'm nervous of software companies that exhibit fundamentally bad design decisions.

Also, the categorising of notes may be handy, but it's far from essential for my use case. On Evernote I have perhaps three or four categories, but no nesting beyond or deeper than that. Notes that I make while mobile are essentially ephemeral records of thought. I don't want to be keeping important information in there long-term -- no matter how good the interface, it'll never beat a wiki, and my wiki is my long term, shared, flexible repository for information with a life span of more than a few weeks. I don't use a notes manager for tracking tasks either -- that's what Trello is for.

Software choices and selection

A quick googling found a few Evernote alternatives, but not many that are genuinely free (such that they can be self-hosted).

SimpleNote and nvALT are offered frequently as worthwhile alternatives, but SimpleNote is non-free (in the only sense that matters here), and nvAlt and its variants such as nvpy rely upon SimpleNote as the backend for its GNU/Linux and Android versions.

So they're out.

Tomboy looks promising. It's a GTK-based app, but I'm not opposed to running those on my Debian KDE machines. It relies upon Mono, which is a massive steaming pile of dependencies, and which does put me off a bit. Combined with the fact that Ubuntu seems to have abandoned Tomboy two years ago, well, it's a bit discouraging.

Looking at Tomboy led me to discover Gnote, a C++ rewrite of Tomboy which is a bit more active in terms of development. It's GTK, but that's tolerable.

Tomboy also led me to Tomdroid, an Android application for making notes that you can sync up to your own hosted server running rainy, snowy or Tomboy-online.

Which, naturally, led me to further explore snowy, which was designed as a Tomboy backend and thoughtfully written in Python, using the Django framework.

But it also seems to be abandoned, so I explored the state of rainy, which seems to be actively maintained and developed, but like Tomboy it unfortunately comes bound up in a massive set of crufty Mono dependencies.

Mono unpleasantness aside, it's pretty impressive that Timo Dörr wrote the basic functionality of rainy over the space of several days.

And, pragmatically, I'm more happy about pulling in mono-complete on a dedicated and safely partitioned server, than I am on my primary desktop, especially as the server is going to be quite painlessly set up and managed SaltStack.

Building the server

I use Debian wheezy (stable) builds, taking a vanilla image I've got on my ESXi server, which I can clone, name, and then run a SaltStack highstate over the top of.

None of this is rocket surgery, to be sure.

And ignoring the boilerplate changes I make with my SaltStack configuration (NTP, basic packages, hardening sshd configuration, importing my ssh public keys, etc) there's very little to do to get rainy up and running.

This SaltStack state file (/srv/salt/app/rainy.sls, in my case) is pretty much it. Caveats include - we're stuck at version 0.5.0 (it's not clear why this lives in the 0.5.1 directory) but I am watching this repo on github, so I'll be notified of upgrades. I don't try to auto-retrieve datastore backups as part of provisioning (this is often a dangerous idea anyway). And, my static blog generator tries to interpretate pairs of "{" characters through its own jinja2 processor, hence there's a space between them below. :)

#### ----------- INSTALL the following packages ------------------------------

pkg-mono-complete:
  pkg:
    - name: mono-complete
    - installed

pkg-libsqlite3-0:
  pkg:
    - name: libsqlite3-0
    - installed

#### ----------  INSTALL (the long way) the rainy cruft  --------------------

# Step 1 - retrieve the rainy zip file
retrieve-rainy-zip:
  cmd:
    # @TODO programmatically retrieve latest version, not hardcoded?
    # @TODO alternatively put version number into pillar
    - run
    - name: "wget -q -nc https://github.com/Dynalon/Rainy/releases/download/0.5.1/rainy-0.5.0.zip"
    - unless: ls rainy-0.5.0.zip

# Step 2 - unpack the zip file
unpack-rainy-zip:
  cmd:
    - run
    - name: "unzip rainy-0.5.0.zip"
    - require: 
      - cmd: retrieve-rainy-zip
    - unless: ls rainy-0.5.0


# Step 3 - install the configuration file
rainy-config-file:
  file.managed:
    - name: /root/rainy-0.5.0/settings.conf
    - source: salt://fs/root/rainy-0.5.0/settings.conf.{ { grains['id'] }}
    - mode: 600
    - require:
      - cmd: unpack-rainy-zip

The settings.conf file that I pull in has been modified only slightly from the shipped version.

I changed the port number from 8080 (I suspect lots of bots knock on that door), and of course I then forwarded that via my router so it's accessible from the outside world. In the settings.conf file I also set a very obfuscated admin password.

Undocumented (non-)features

Desktop clients are not your friend

Gnotes will not synchronise to my rainy server. Well, perhaps it will, but it would involve installing wdfs just to find out, and wdfs smells a lot like abandoned software (perhaps it's just been incredibly stable these past several years), and then talking (perhaps) to rainy via webdav. But, I really couldn't summon up the necessary levels of care required to investigate this.

Tomboy (desktop client) may very likely talk to rainy, but I'm uber-reticent to install several dozen crufty Mono-related packages on my laptops and desktop machines.

For the time I'm quite happy with the web client. From a use-case point of view I find KDE is much better at restoring all my open windows and tabs in chromium, so I generally just have a 'Being organised' browser window that includes tabs for things like trello, my calendar, airdroid, and similar. I think this is going to continue to work out to be more effective, and certainly easier to deal with, than a dedicated desktop application.

Security by afterthought

You can log rainy's output directly, by using the -vvv parameter at run time - but redirecting it to a log file is left as an exercise for the reader. I'll probably do this such that I can crank up fail2ban to give my system a bit of protection against brute force attacks.

Timo Dörr told me that the admin user can't change another user's password because this is a security feature -- the user's password is the encryption key for their notes.

While this is a lovely design aspect it does mean that absent that ability for a user to change their own, you really need to be sure that you have a sufficiently complex password, that you don't use anywhere else. I've yet to run through some tests of changing passwords and trying to re-sync back up to the server from scratch, and/or do disaster recovery after a rebuild of the server VM.

Timo did indicate that sometime soon there'll be an API call for users to change their own password, which result in all their notes being re-encrypted behind the scenes. There may be a performance penalty for this, but, realistically, this is going to be blindingly fast unless your user has a stupid amount of note data.

Anyway, from an overall security perspective, some comfort can be had from the fact that it's only my notes -- there's some vaguely sensitive stuff in there, but nothing particularly frightening for me if the world knew it. I have a full copy on my phone, and I do frequent full backups from the rainy server back to a box I trust (we are talking about tiny quantities of data, after all). And one of the main reasons I have rainy running in its own VM is, of course, to isolate it from any security breaches.

So for me right now it's a trade-off -- a simple notes system, with a fast Android interface, that I can feel confident will retain information I put into it, coupled with frequent and regular backups in case something goes wrong, versus the massive unknown that is Evernote.