Along with the million other things I’ve been trying over the past year of seeking self-improvement, journaling is one of the ones I’ve had partial success with (well, more than zero-success at least). Here’s some implementation detail on my setup and how I’ve kept it as bare-bones as possible, backed-up in the cloud and, most importantly for my tin-foil fetish, secure.
I want something easy to maintain & setup (ideally zero-maintenance) and I don’t really want to have to pay for it for the rest of my life. I want it to be future-proof, I don’t want to come back to this in a few years and find nothing supports it’s format. Oh and I also want it to be secure as heck. The goal here is to brain dump my day, including all the thoughts I’ve had about it. I don’t want it accidentally being accessed by some randoms, or even non-randoms, without my express permission. Simple enough right?
So, we want a simplistic file format. Any sort of proprietary format or under-popular open source one is only going to cause me pain in the future. This led me to a nice and obvious solution: Text files! They’re infintely interoperable, have been around forever, and will still be supported in a millionty years so it fits all the use-cases. For bonus points let’s make them markdown files (it’s just giving them md file extensions after all), that way we can add in links or a bit of formatting if we want to later and it’ll be pretty easy to turn it into HTML in the future if we fancy that too.
Ok, next up storage. Something like google drive or dropbox would work, but I don’t want these having to sit next to my other life-admin documents that I put in those kinda places. I also don’t want to accidentally delete this stuff, or parts of this stuff, when I’m tidying things up. Version control systems are good for making sure that’s very hard to do, and they come with free decentralized backing up on my machines if I’m into that. Git it is! Also, the interface to wherever I cloudify this stuff is completely interoprable and segmented into it’s own repository, so migration and organisation will be a breeze. Heck, I could even move them to something self-hosted if I cared enough (I probably don’t).
Ok so, markdown files, stored in Git. So far so good, but what about security? This is a super-secret private Journal right? Well, the way I see it there are 2 main attack vectors: the files sat on my machine(s) and the files sat up in whatever cloud storage I put them in (I’m discounting in-transit because whatever I use will have ssl). My machine I worry less about, but the main issue is these pesky cloud providers. I just don’t trust that they keep this info as secure as I need it, which means that I need to figure out a way to encrypt it.
Well, lucky for me, PGP is a thing :D A few simple commands can get me an encryption key that’s going to be pretty unbreakable for many years to come*. The one potential issue with this is that it’s not trivial to setup. With security, the biggest vulnerability is the squishy grey matter inside your head that regularly does stupid things (remember when you used to think shirts with flames on were cool… ugh idiot). Encrypting things with a PGP key is by no means hard, but we want to reduce the chance of human error as much as possible here. Thankfully, I’m used to doing this kind of thing in my day job; automating all the repetitive stuff. Should be a doozy.
So, we want some sort of scripting language, bash’ll do. But we want the interface with it to be as simple and clear as we can, so let’s not write it in raw bash, let’s use a Makefile, they’re universal enough. Here’s how we get a simple “create today’s markdown entry” to keep things nice and organized, and we open** it up using whatever our system’s chosen markdown editor is (in my case I use Mark Text).
# Set the entry to todays date if not specified.
ifndef entry
override entry = $$(date +%F)
endif
open:
open $(entry).md
Next up we want to be make sure this is easily encrypted. I haven’t gone so far here as to integrate with my editor to auto-encrypt it once it closes, but this feels like an integration too far. I’d be writing a lot of scripting just to work with an editor that might be dead in a few years. Instead we simply write ourselves a save method that generates an encrypted file and wipes any raw ones***.
save:
gpg --encrypt --recipient $GPG_EMAIL $(entry).md
$(MAKE) clean
clean:
rm *.md
And last, but not least, we need to back this up on the interwebs. This is easy right, just create a new repository on your git-host of choice and then run the below in your journal folder.
git init
git add Makefile
git commit -m "Can't forget to push this awesome Makefile I'm using."
git remote add origin [ADD YOUR URL HERE]
git push -u origin master
Next, we just need to update our Makefile to push this up when we’re saving:
save:
gpg --encrypt --recipient $GPG_EMAIL $(entry).md
git add $(entry).md.gpg
git commit -m "Saving $(entry).md.gpg to repo."
git push
$(MAKE) clean
I’ve popped the file that I use for this in it’s entirety below, but I almost didn’t. I guess, the whole point of this rather simple post is that it’s so bloody simple. This is how I’m jounaling right now. It took me very little time to come up with and so far, zero time to maintain. It’s secure, robust, pretty (because of my editor) and it fits into my workflow easily.
Often when we’re faced with a need these days we take the “don’t re-invent the wheel” mantra and hunt for the newest saas product that fills our need. But often, they’re selling you a swiss army knife, when all you need is a spork. This little script was a nice reminder that sometimes if you just use your brain a little, maybe you can build what you really need pretty easily. One less subscription fee to pay each month isn’t a bad outcome either.
# Set the entry to todays date if not specified.
ifndef entry
override entry = $$(date +%F)
endif
open:
if [[ -f "$(entry).md.gpg" ]];
then gpg $(entry).md.gpg;
else;
touch $(entry).md;
fi
open $(entry).md
save:
gpg --encrypt --recipient $GPG_EMAIL $(entry).md
git add $(entry).md.gpg
git commit -m "Saving $(entry).md.gpg to repo."
git push
$(MAKE) clean
clean:
rm *.md
* But not forever. Whilst you could publish your encrypted data, and no-one could really access it now, once it’s out there it’s out there for ever. Like EVER ever. Which means eventually, someone will be reading that info, and you’ll just be gambling that you’ve been dead long enough to not care. As such, I’d advise that you still put some practical preventions in place like sensible password protections on the cloud services you use to store this etc.
** The open command is mac specific, but swapping it for something that’ll run on your OS should be trivial.
*** I’m too lazy to write a post on how to use gpg, here’s one somebody else put way more effort into.