Over the past few months I’ve ended up, for reasons out of my control, becoming much more of a digital nomad than I had planned for.

I’ll write more about that in a bit I’m sure, but right now I wanted to share with you a very specific tip that came in use for me.

To track time spent working on client work, I use the linux utility hamster. There are web based ones of course, but this was simple and does exactly what I wanted to do, but the downside is that it was one computer only.

This wasn’t a problem for the most part, since I almost always worked using my home desktop machine. However, I’m now spending much more time on client site, or otherwise on my (rather old and in need of an upgrade) laptop. This meant I would always remember to keep my tracker updated, and it also made generating invoices were a problem.

Luckily, Hamster uses a simple file to store it’s tracking data, so all that was required was to find a way of sharing it. I already had an ownCloud server (if you want to use NSA file storage, you can use Dropbox if you like), so all I had to do was move the hamster db directory, and then symbolically link to it on all my machines, as so:

On your main machine (the one with the most up to date db)…

Let ownCloud sync up, and then on your client machines…

If you’re using Dropbox, obviously change the path name accordingly.

Hope you find this as useful as I have!


So, it’s been a little while since I’ve posted anything, but, I’m back now, so here’s a quick Emoji plugin for Known.

I wrote this plugin (which is basically a Known wrapper around jloutsenhizer’s Javascript Emoji renderer) to scratch a particular itch of mine, whereby some Bridgy backported comments from Facebook were being rendered with Unicode placeholders.

Happy Christmas!

» Visit the project on Github...


In my earlier post on this subject, I gave a brief overview of the Known API. I hope people found this useful.

Anyway, it is the nature of development that things change, and recently I pushed a patch that fixed a couple of potential security issues. I won’t bore you with the details, except to say that this might well have an effect on how you use the API.

Sessions are destroyed after page display

In the older instance of the API, once you had authenticated, HMAC validation was short circuited and you were treated as logged in on subsequent requests (provided you remembered to store cookies). This was really a workaround to handle the way that Known would forward you to a created object after creation, and since this was a new URL, you’d need a new HMAC, but the 302 would happen before you could generate one.

Now, you are only logged in for the duration of the page visit, and sessions are destroyed after the page has been sent. Each request must now be individually signed.

Which brings us to the next big change..

No more automatic forwards

Because each page request must be individually signed, it is no longer possible to forward you automatically to the created object. It is also no longer necessary for you to configure CURL to automatically handle 302 responses.

Instead, if you’re making an API request, instead of forwarding, Known will return some JSON containing a location for your next GET request, e.g.:

This also gives room for extension.