blog.polynom.me/content/2019-10-06-Road-to-Foss.md

+++
title = "Road2FOSS - My Journey to Privacy by Self-Hosting"
date = "2019-10-06"
template = "post.html"
aliases = [ "/Road-to-Foss.html" ]
+++
About one year ago, I made plans to ditch many of the proprietary services that I used
on a daily basis and replace them with FOSS alternatives. Now it is a year later and
while my project is not done, I really did quite a lot.

<!-- more -->

## History
But why do all this?

The answer consists of three main points, though they are weighed differently:
1. Privacy: The inspiration for this project came from the fact that I did not trust my messaging application back then. It was proprietary and probably collecting all the data it could, thus I wanted to get away from it.
2. Learning: I really enjoy tinkering with computer hardware, software and am quite interested in server administration. Hence, I thought it would be a greate learning opportunity for me.
3. Fun: I do enjoy this kind of work, so I thought it would be a fun, but quite major, side project.

I knew that it would be a major undertaking but I still wanted to give it a try.

## Instant Messaging
Judging by the amount of personal data I leak when texting people I know I wanted to switch IM services
as quickly as possible.

At this stage, there were three candidates for me:
- *Signal*
- *Matrix* with Riot
- *Jabber/XMPP*

Originally, *Signal* was my preferred choice since I really liked its interface. But the problem with Signal,
and I do not blame the developers for this one, is that the service only works with a mobile device running
the app. If I wanted to run *Signal* on my computer because, for example, my phone is broken or the battery
is empty, then I just could not since it requires my phone to be online. Also, which I learned only just recently,
*Signal*'s *Android* app has a bug which [drains the phone's battery](https://github.com/signalapp/Signal-Android/issues/8658)
when one does not have *Google services* installed on their phone.

*Matrix* in combination with Riot was another idea of mine. But here the problem was the mobile app. It
seemed to me more like the interface of messengers like *Slack* and *Discord*, which I personally do not like
for mobile Instant Messaging. When I last looked at the entire *Matrix* ecosystem, there was only one
well-working client for mobile, which was Riot. Additionally, the homeserver was difficult to set up; at least much more than
*Prosody*, to which I will come in the next paragraph. Moreover, I read in the the [*Disroot blog*](https://web.archive.org/web/20190921180013/https://disroot.org/en/blog/donating_floss) that they have
quite some problems with their *Matrix* homeserver as *"[...] [k]eeping room history and all metadata connected to them forever
is a terrible idea, in our opinion, and not sustainable at all. One year of history is way too much already [...]"*. This
was the end for the idea of self-hosting a *Matrix* server.

*Jabber/XMPP* being something I saw only once way back when browsing a linux forum, I became interested. It
checked all my requirements: It is cross-platform, as it is only a protocol, allows self-hosting with FOSS
software and, the most important factor, includes End-to-End-Encryption using *OMEMO*. I also started to
appreciate federated software solutions, which made *Jabber* the clear winner for me. Tehe *Jabber* clients
that I now use on a daily basis are also very fine pieces of opensource software: *Conversations*' interface
is simple, works without draining my battery and it just works. *Gajim*, after some configuration and tweaking,
works really well, looks clean and simple and I would really love to replace *Discord* on the desktop with
*Gajim*.

Recently, I also started to use *Profanity*, which seems a bit rough around the edges and sometimes does not
work, but maybe I am just doing something wrong.

In terms of server software I initially wanted to go with *ejabberd*. But after seeing its amount of
documentation, I just chose *Prosody*. It is the software that was the least painful to set up with all
requirements for modern messaging being covered by it internal or external modules. It also never crashed;
only when I messed the configuration up with syntax errors.

Since I use *Discord* and it is more difficult to bring people over from there, I went with a compromise
and started to bridge the channels I use the most to a *Jabber MUC* using [*matterbridge*](https://github.com/42wim/matterbridge).
Thus I can use those channels without having to have the *Discord* app installed on my devices.

Another use I got out of *Jabber* is the fact that I can create as many bot accounts on my server as I want. While this
sounds like I use those bots for bad things it is the opposite: I use them to tell me when something is wrong
using *netdata* or for the already mentioned bridge between *Discord* and *Jabber*.

## VoIP
VoIP is something that I use even more than plain Instant Messaging, which is why I wanted to self-host
a FOSS VoIP-solution. The most commonly used one is *Mumble*, which was a run-and-forget experience. Especially
when not using the full server but a smaller one like *umurmur*.

## Code
At first, I used *Github*. But after *Microsoft* bought it, I was a bit sceptical and switched to *Gitlab*, which
worked really well. It was even opensource so I started using it. But after some time, I found that
there are some things that annoy me with *Gitlab*. This includes it automatically enabling "Pipelines" when I
just created a repository even though I never enabled those.

That was when I came across *gogs* and *gitea*; the latter being my current solution. I wanted a simple
software that I can just run and has a somewhat nice interface. Why the nice interface? I want that if people
look at my code that it feels familiar to browse it in the browser. Also, I can invite friends to use it if
they also want to get away from proprietary services and software.

My instance has registrations disabled as I do not have the time to moderate it, but I have seen that federation
of some sorts, in the context of *ForgeFed*, is being discussed on the issue tracker, though you should not quote
me on this one.

*Gitea* was mostly a run-and-forget experience for me and is working very well.

## Personal Information Management
Since I've started to use calendars more, I wanted a solution to sync those across my devices. Before this entire
project I was using *Google*'s own calendar service. Then I started using *Disroot*'s NextCloud to synchronize
calendar data. However, it not being encrypted at rest was a concern for me as my calendar does contain some
events that I would not like an attacker to know as this would put the attacker in a position where sensitve
information can be deduced about me.

After some looking around, I found [*EteSync*](https://github.com/etesync). This software works really great, given that the server is just
a simple django app that stores data and does user management and authentication. The *Android* app, in my case,
does most of the work and works really well. The only problem I had was the fact that *EteSync* has no desktop
client. They provide a web app and a server that bridges between regular DAV and *EteSync* but nothing like
a regular client.

Since I used regular WebDAV services, like the *Disroot* one I mentioned earlier, I have [*vdirsyncer*](https://github.com/pimutils/vdirsyncer)
installed and configured only to find out that they dropper support for *EteSync* in the last version.
Wanting a tool like *vdirsyncer* but for *EteSync* I went to work and created [*etesyncer*](https://git.polynom.me/PapaTutuWawa/etesyncer).

## EMail
Most of my online life I used proprietary EMail-services. Most of that time I used *GMail*. Since I bought a
domain for this project and have a server running, I thought: *"Why not self-host EMail?"*. This is exactly
what I did!

I use the "traditional" combination of *postfix* and *dovecot* to handle incoming, outgoing EMail and IMAP
access. Since I use [*mu4e*](https://web.archive.org/web/20190921054652/http://www.djcbsoftware.nl/code/mu/mu4e.html) in combination with *msmtp* and *mbsync* for working with email, I did not
install a webmail client.

This was the most difficult part to get working as the configuration sometimes worked and sometimes not.
The main culprit here was *DKIM* because it changed the permissions of its files at startup to something else
which made *openDKIM* crash. Now it stopped doing this but I am not sure why.
What made the EMail-server so difficult was also the fact that so much goes into hosting an EMail-server I never
thought about, like *DKIM*, *SPF* or having a *FQDN*.

At this point, it pretty much runs itself. It works, it receives EMails, it sends EMails and it allows
me to view my EMails via IMAP.

Coming from *Protonmail*, the only thing that I am missing is encryption of my EMails. Since not every person
I contact using EMail uses or knows *PGP*, I would like to encrypt incoming EMails. While there are solutions
to do this, they all involve encrypting the EMail after they are put in the queue by *postfix*, which puts
them on disk. Hence, the mail was once written in plaintext. While I would like to avoid this, I have not
found a way of doing this without digging into *postfix*'s code and adding support for this.

## Blog
I wanted a blog for a long time and since I had a spare domain lying around, I decided to create one. While
I could have gone with a solution like *Wordpress* and the like, they were too complicated for my needs.
So I just went with the simplest solution which is using a static site generator: *jekyll* in my case.

This is one of the points where decentralization was a huge factor directly from the start, as this is exactly
what the web was made for, so I was actively avoiding any non-selfhost solutions. While I could have gone with
a federated solution like *write freely*, I chose the staic page generator as it was much simpler. And because
I love writing in Markdown.

## Webserver
Since I now use *GPG* to sign any emails that I send, I needed a way of exposing these keys to the public. While
I could have gone with a keyserver, I decided against it. Admittedly, I did not look into self-hosting a
keyserver but this was not my plan. I want to keep everything simple and prevent myself from installing too many
services on my server. This led me to just putting my public keys on the server and pointing my
webserver to them.

Since I run multiple services that are accessible via the browser, I needed the webserver as a reverse proxy,
pointing my different domain names to the correct services. This way, all services can run on their own ports while
the reverse proxy "unifies" them on port 443.

## Conclusion
All in all I am very happy with my setup. It allows me to host my own instances privacy-respecting software the way I like
to. It gives me something to do and allows me to learn about system administration and different tools like *Docker*
or *Ansible*. So all in all, although the project has no real end, I would say that it was and is a huge success for me.

During the course of this project, I also switched services like my search engine or the software with which I watch videos
but as I do not self-host these, I did not mention them.