About a year ago, I started using Syncthing to replace Dropbox. I did so for the usual reasons:
- I had started to care more and more about privacy
- The prospect of some external service deleting my files is horrible to say the least
- At the time, the Dropbox App on Android would not download one's files. Workarounds like Dropsync were slow.
- It's proprietary software.
- I was just moving from Windows to Debian, and getting Dropbox to run would require work anyway. So getting something else to run was not much of an additional inconvenience.
Now, the first two points can be summed up to a distrust of centralized systems. Especially if they are not in my hands, but decentralized systems are preferred even if I could control the centralized one.
Switching from Dropbox to Syncthing meant that the synchronization of files was taken care of, but what about the other things one uses every day? Address books, calendar information, to-do lists, et cetera. These are usually also synchronized, say, using one's Google Account. Additional things add to this, such as taking and synchronizing notes.
I must add, that I have a strong preference for programs storing their data in flat files, and that I have also slowly developed a preference for terminal-based programs. Also, I am only borrowing my web space - I don't have a server that I could install anything on.
I'll use the rest of this post to outline the problems I have encountered in moving to new applications more compliant with my described wishes. Maybe it's useful for some - in the worst case it is some more links to the sites of nice projects.
Probably the single issue I care most about is having access to my bibliographical database. I was using JabRef already before moving to Linux, and it saves it's database in BibTeX files. These are essentially text files with a special formatting, say, easy to synchronize.
On Android, I was using Refmaster to connect to Dropbox and navigate my bibliographical database from their.
This setup has not changed much: using Syncthing, I managed to take Dropbox out of the equation and can now directly open the files locally on my phone. That's all.
Earlier, I was using Microsoft's Onenote for note-taking and the synchronization of my notes. As there is no client for it on Linux, I ran into a problem pretty quickly - and at first reacted by not writing longer notes anymore. For shorter things, I subsisted on sending myself Emails.
A solution for this is however not that hard to find. I am now writing my notes in Markdown, saved in flat files and thus easily synchronized. On my Debian machines, I am using gedit to read/write them, on Android an app called Writeily Pro (no worries, despite the
Pro in it's name, it's free as in free beer, too).
Taskwarrior is saving to-do list entries in plain text, so Syncthing is sufficient for synchronization once again. It also comes along with an own synchronization server, but I have not yet tried that out.
Status: Solved, kind of
For my address book, I previously used the usual Android way. Just linking everything to one's Gmail account. Oh, horror! This is not just my personal data, but it's personal data of others. Which is to say, I am even more concerned about data protection in regard to these than about all the other data mentioned above and below. On the other hand, I just rarely open my address book anyway. Where necessary, the respective chat apps have some contacts - and for everything else, I could theoretically just grep through vcards.
To have mobile access to my address book, I keep the data on a server and use a self-written web frontend to viewing vcards. It's not the best way, but definitely more responsible than Gmail.
Status: Work in progress
For keeping a calendar, I was previously also using services linked to my mail accounts. Unfortunately, it turns out that calendars on Android are very hard to use otherwise. Getting synchronized calendars is thus the only major problematic point in my endeavours described here.
I am now using khal for managing my calendar on my Debian machines. Khal is a Python-based command line calendar, that stores events .ics files. Now, there seem to be two different concepts of how to work with .ics. First, one might store all events in a file each; second, one might create one large file representing a whole calendar. Khal uses the former, calendars published on the web the latter.
Android on the other hand natively demands a CalDav server to synchronize events with. As I want to avoid centralized services not in my control and do not have access to a server I could install anything on, this is clearly not an option. Also, calendars to be displayed in the calendar app are stored in a root-only directory, that I cannot directly synchronize with as I could with everything else.
I thus had to search for a workaround. On searching through F-Droid, I found some interesting apps: first, there is the Offline Calendar app (which is accompanied by an additional import/export app), then there is ICSdroid.
Both solve the problem of creating calendars without a CalDav server to synchronize with. The Offline Calendar app simply creates, well, an offline calendar, whereas ICSdroid allows the user to add new calendars based on subscriptions of calendars published as .ics streams either on the web or locally.
Since the import/export app does not work automatically, using it would have been a major hassle. I decided against it.
Instead I decided to go the ICSdroid route, even if it means that I can only edit my calendar on my Debian machines. To create entries on my phone, I need to create it in a local calendar and then import it into my general one. Not a pretty way, but it works.
Now, I still had the problem of unifying single .ics files into a stream per calendar. For this, I wrote a little program to do so. I have uploaded the code here (I admit, the code may not be the prettiest, but writing it also served as a way play around with Rust a bit).
Running this program will unify the .ics files into one stream. From there on, I can synchronize them with my phone and subscribe locally. I additionally upload the calendars to the server, to also be able to access them directly from the web or to synchronize from there. For this, I have written a PHP web frontend, whose code can be found here and on GitHub.