Feedback on the docker compose setup

[cameronj86]

Appreciate the work everyone has put in. I have been using taskwarrior for 2-3 weeks and set an hour aside today to get sync up and running. +4 hours later and with the sync still not working, I just wanted to give some feedback.

I see that there are efforts to make things easier for users re:docker (#53) and I appreciate that. Typically, docker compose files are seen as the easy route thanks to standardization/containerization making it harder for user error (when given explicit instructions), while bare metal OTOH has to account for the OS et al and is ripe for potential conflicts.

With the current docker-compose setup, the requirement is a server with ports 80 and 443 open to the Internet and with a fixed, publicly-resolvable hostname and I really think there needs to be more attention given to 1) what this actually entails and 2) who it applies to.

If I'm understanding correctly, the 'simpler' route actually requires a substantial investment that is a much larger barrier to entry than the average self-hosting project. It requires that you have already purchased a domain and/or set up that domains' hosting and/or configured the A records and/or set up the CNAME/TXT records and/or set up your webserver and/or set up SSL certs and/or set up firewalls if you're self-hosting it yourself, etc.

And In terms of who this applies to, this is a requirement for anyone running tw v3 that wants basic sync functionality, and/or wants to get things up and running ASAP. I can appreciate the desire to push users towards more secure setups, but this level of friction for a feature that is automatic/hidden in most software is a big ask.

Perhaps my expectations are biased a bit as someone that regularly self-hosts, but 1-2 years in, I still don't own a publicly-resolvable site and rarely come across docker setups where that's been an issue. Things like KO Reader's book sync being up and running in two commands and having a docker container even tho it's basically syncing simple metadata.

I accept that taskwarrior is a technical tool for technical people. I run Debian on all my devices and don't mind a bit of troubleshooting and security, but I also believe that basic sync functionality is such an important feature that the simple solution shouldn't require that you already know (or quickly learn) how to host your own site as a pre-requisite.

I think that a more efficient solution could be to make the docker compose a containerized version of the simple http server, with the existing docker compose setup relabeled something like docker-compose.yaml.moreSecure. Alternatively, more explicitly direct users towards the http server in documentation, given the lack of necessary prior knowledge/investment.

[ryneeverett]

With respect to a server with ports 80 and 443 open to the Internet and with a fixed, publicly-resolvable hostname, it's not clear to me what real difference you're seeing with KO Reader. it looks to me like they use a self-signed cert with nginx just like caddy does. I believe caddy works with localhost too. On both services you'd have to open those ports and have a static hostname or IP address if you want it to work remotely.

[cameronj86]

I think I was partially conflating my issues resolved in #104 a bit here...

Many people want to sync tasks across personal devices on their LAN ie a laptop and a phone. And OTOH, many people want to sync between work and personal devices, which traditionally necessitates a publicly accessible connection. I was of the impression that the former required a setup that mirrors the latter based on the publicly accessible requirement

But, AFAICT, if it can run on localhost w/o a port being opened, then it doesn't actually need to be publicly resolved unless I'm misunderstanding something.

[ryneeverett]

But, AFAICT, if it can run on localhost w/o a port being opened, then it doesn't actually need to be publicly resolved unless I'm misunderstanding something.

That sounds right to me. Did you try setting TASKCHAMPION_SYNC_SERVER_HOSTNAME to "localhost" or "127.0.0.1"?

[djmitche]

I'll offer my perspective here, starting at the large scale and zooming in.

Taskchampion-Sync-Server is just one option for sync. There are currently two others (AWS and GCP). All three have caveats, so users might prefer one over the other, but we would like to support them all. In particular for users who don't have systems where they can run a server, TSS is not a good choice. Hopefully in the future there will be other sync options as well!

anyone running tw v3 that wants basic sync functionality, and/or wants to get things up and running ASAP

I would expect those folks to use one of the cloud options.

For those who can run a server, we want to make the simplest path follow modern best practices, and that means using HTTPS. HTTPS that requires a certificate matching the hostname. The simplest way to do that is with the docker-compose config, as that generates its own key and certificate and gets it signed. However, it requires a public hostname that the Lets-Encrypt servers can resolve.

So there's sort of a decision tree based on user skill and resources. We also support other choices, but those come with the requirement to do a bit more work to get it going. For example, running TSS as a daemon on an existing system is possible and supported, but requires writing a .service file or a .plist on a mac or any number of distro-specific things, as well as configuration of a reverse proxy to terminate TLS connections or a decision to not use HTTPS. It's possible to write your own sync server -- the protocol is fully documented. It's possible to run just the TSS docker image and not the whole docker-compose fleet, maybe in an existing Kubernetes or ECS environment. We've just had to be parsimonious in the setups for which we can provide clear "out of the box" guide-style instructions, and leave the rest of the setups to be built using the reference documentation.

I think what's lacking, illustrated between #104 and this issue, is a clear document laying out the whole decision tree, from deciding on an approach all the way down to what to type in which files. It seems like that would be a great document to add to https://taskwarrior.org/docs/, the backend for which is https://github.com/GothenburgBitFactory/tw.org. #104 also identifies a bunch of places where we're missing reference documentation or useful pointers to it.

With all that said, would you be interested in taking on some of the work to organize this information and improve the experience for the next person?

[ryneeverett]

My reading of the docs is that self-signed certs should work automatically for localhost, so I don't think we should have to change anything for this to work.

[djmitche]

Ah, that may be a new thing where browsers are willing to trust non-public certs for localhost. That's good news, though!