task.00dani.me Taskserver

Hi! This is a Taskwarrior-compatible taskd server. You'll want to connect to it using a local copy of Taskwarrior.

The recommended settings to add to your taskrc are:

taskd.server=task.00dani.me:53589
taskd.ca=~/.config/task/isrgrootx1.pem
taskd.certificate=~/.config/task/me.cert.pem
taskd.key=~/.config/task/me.key.pem
taskd.credentials=Public/Your Name/your-user-id

Taskwarrior's documentation is pretty vague about what these parameters are for, and in particular which of these parameters should be considered secrets and which can safely be committed to your dotfiles. So here's my own findings about each of the above settings:

taskd.server

The hostname and port for your taskd, naturally. These are effectively public information and you can commit them safely. Note that the port is required - Taskwarrior does not treat 53589 as a default, for some reason. Pretty much every taskd will be listening on that port anyway, but I suppose you might want to listen on a different port if you have to deal with a weird firewall?

taskd.ca

Path to the certificate authority your taskd will use to identify itself. This setting is optional if you're using a publicly-approved certificate authority, such as Let's Encrypt, because Taskwarrior respects your system keychain. You only really need to set this if you're using a self-signed CA for your taskd's server certificate, and with the ubiquity of Let's Encrypt there's no real reason to do that.

taskd.certificate

Path to the client certificate your local Taskwarrior will use to identify itself to your taskd. Technically this certificate is public information and can be committed, but it's useless without the associated taskd.key, which is private information.

It's very important to note that the client certificates that Taskwarrior uses do not identify a particular user of the associated Taskserver. Client certificates constitute authorisation to use the Taskserver, not authentication to access and modify a particular user's tasks. For a self-hosted Taskserver like this one, it seems to make the most sense to treat the client certificates as "device keys" and to create one for each device that intends to sync your tasks. Individual client certificates can be revoked from the Taskserver, so this approach allows you to revoke a certificate if you lose the device it belongs to.

taskd.key

The private key associated with your taskd.certificate client certificate. Being a private key, this is private information. Don't commit it to your dotfiles.

As mentioned above, this key does not authenticate you as a particular user of the Taskserver, just authorise you as someone who's allowed to use the Taskserver at all. As I suggested above, treat your taskd.key as a device key rather than a user key.

taskd.credentials

The documentation for this setting is the vaguest, in my opinion, so let's talk about what it does. Your taskd.credentials consist of three separate values: an organisation name, a user name, and a user identifier, separated by forward slashes. I'm going to explain each of them, but the summary is: don't commit this to your dotfiles.

The organisation name identifies the group on the Taskserver that contains your user account. Generally this is set to the recommended default, "Public". Eventually, the Taskserver will actually do something with organisations, such as allowing users in the same org to interact, but currently it does nothing special. It's effectively public information and can safely be committed to your dotfiles.

The user name, which is usually your full name, non-uniquely identifies your particular user account within the chosen organisation. The user name doesn't actually need to be your full name: Inthe.AM uses the local part of your Gmail address as the user name, for example. This field is also safe to commit to your dotfiles, because your name is naturally public information.

Finally, the user identifier is a UUID generated automatically by the Taskserver when you initially register. This identifier is essentially treated as a password and is the only thing that authenticates you when you connect to your taskd - remember, your client cert authorises you to access the Taskserver, but does not authenticate you as a particular user. As a result, you should not commit your taskd.credentials to your dotfiles, even though two thirds of it are public information.