Freedombone Blog

Freedom in the Cloud

Integrating RSS

Twenty years after the invention of RSS its fortunes as a protocol appear to be dwindling. The Firefox browser has done an especially lamentable job of making RSS easy to use. The main reason for that seems to be not that it isn't a useful technology but that it doesn't readily enable the kinds of surveillance which largely fund the contemporary web. There is typically no tracking on a list of links and traditionally there havn't been many attempts to insert ads into RSS feeds. RSS feeds are also not subject to any AI-driven timeline algorithms which bias some content above others.

RSS readers have existed within Freedombone for a long time, first with Tiny Tiny RSS then SmolRSS and now there is integration of RSS into the web interface via a system called RSS Garden. The aim is to make subscribing to and reading RSS feeds maximally convenient.

Image description

There's an RSS button you can select on the admin or home screens on the web interface, which lists entries for feeds you're subscribed to and you can add or remove feeds by clicking on the title at the top.

Image description

And of course the web interface is either available on the local network or via an onion address.

Image description

Because the home screen may be available to multiple members of your household adding and removing feeds is only accessible by the admin, so that for example someone can have parental control of what feeds get listed. Later this might be elaborated into a true multi-user reader experience.

RSS integration is currently only available on the buster development branch which is expected to be formally released in one or two months time.

Speeding up Translations

The way that translations happens in Freedombone is maybe not optimal but it's good enough, especially considering that changing the language of the web interface is something which is only going to happen once after setup for the first time. Previously this was quite slow, because behind the scenes what was really occurring was the running of a lot of sed commands on each screen.

To speed things up the script which changes language has been rewritten in python and loads the translation table into memory. This reduces the amount of time to translate all strings on all pages down from multiple minutes to thirty seconds on a Cubieboard with an SSD. That's still an appreciable duration and so additional "please wait" screens have been added. The wait screens make changes of language or theme much nicer and a lot less confusing. Possibly this might also be an opportunity to show some informational images during the wait, similar to installing Ubuntu or some other distros. Without wait screens there is a twilight zone in which some things have changed and some things havn't.

Image description

These changes currently only apply to the unreleased buster branch. With the release of Debian 10 expected soon (within a couple of months) the buster branch is where most of the action is happening.

Community Networks

Although Debian 10 hasn't officially been released yet development on the buster branch of Freedombone is now well advanced. Apart from some new apps some other new features will be integrated VPN using Wireguard and Community Networks which is intended to help set up or join geographically local municipal networks, similar to NYC Mesh, Guifinet or Freifunk.

The community networks screen within the web interface allows you to select a network or start a new one, via "Your Community". You can then enter your geocoordinates and view a map showing other servers (called "nodes") in your area. Since community networks are often implemented via wireless rooftop dish antennas this allows you to judge whether there are any nodes in range which also have line of sight for maximum bandwidth, or where the appropriate places to lay fibre-optic cable might be.

Community Network Screen

The maps are from openstreetmap.org and are generated using staticmap to avoid the need for javascript. There is also a button to export in KML format so that you can use Marble or other compatible viewers.

In the US and Canada community networks such as NYC Mesh are new and somewhat experimental, but in some areas of Europe they are becoming mainstream and sometimes user-owned network infrastructure is the primary way in which internet is delivered. Historically, such networks emerged because conventional ISPs were unwilling to deploy broadband in poor or remote areas and so users had to do it themselves or go without. As network hardware gets cheaper and easier to deploy the public ownership of networks becomes the logical extension of public ownership of software (FOSS).

This is really just the beginning of community networks integration within Freedombone and there's more which could be done to help guide you through the process of setting up antennas and installing network switches. Probably the 2020s will be the decade when such things become a common aspect of internet access.

Beginning on Buster

In the last couple of days I've started work on the buster branch of Freedombone. "Buster" is the codename for Debian version 10. It's not officially released yet, but is expected to be within the next few months and by the time that happens there should be an equivalent Freedombone version. I expect that it will take a while to get fully working, but I already have an image which builds and a few apps which are confirmed as being installable. Email also appears to work with only a small fix to Dovecot settings. Searx search and the web interface also work.

Based on initial tests I think the upgrade from Debian 9 to 10 is going to be easier than it was from 8 to 9. It will still take quite a while to test the installs for each app, and sometimes different package versions need to be used.

Debian 10 brings PHP version 7.3, and that means that Pixelfed and some other new apps will be installable. It will also be able to support more single board computer models and TLS version 1.3 will arrive.

The future is looking quite good for self-hosting and the stability of the Debian GNU/Linux operating system makes it possible to run a server at home without constant maintenance.

Muted Words in Pleroma

There has been a recent addition to Pleroma which allows for posts containing matched keywords to be blocked. It's already possible to block individual fediverse addresses or entire domains and so this adds even more granularity such that you can get a good level of control over what does or doesn't get into your timeline.

This is now accessible in Freedombone via the blocking controls on the settings screen. There is a button called muted words which then allows you to define a list of words or phrases to be blocked. The blocking will apply both to local and federated timelines and it's very similar to the feature with the same name on Twitter.

Image description

Muted words already applies to email and XMPP and so the settings screen allows you to define a single policy which will be applied to any installed apps. This might also be useful for parental control if you have a few members set up.

If you're running on a single board computer the application of blocking rules can be a bit slow and it can take a few minutes for Pleroma to become usable again after a settings change, because it needs to recompile. During this time you can expect to see a 502 gateway error.

The rush to TLS

Issues which I've been encountering recently with XMPP are all about TLS and differing threat models. It seems as if LetsEncrypt has been around for ever, but really it has only been usable in the last two or three years. During that time an increasing number of internet applications just assume that TLS authentication is in place.

Before LetsEncrypt XMPP servers typically allowed self-signed TLS certificates or no certificates. Recognition by Certificate Authorities (CAs) wasn't mandatory. But increasingly now it is. This is all fine except in cases where you don't need TLS or where Certificate Authorities are untrusted and belong in the threat model. That's usually the case if you're running XMPP on onion addresses. After all, CAs include numerous dodgy companies and entities like the Chinese government.

So if you're setting up an XMPP server with the intention of using both clearnet and onion addresses then there's a conflict of interests between the two routing worlds. The clearnet would like CA-recognized TLS certificates to always be used. The onionspace would prefer that to be optional or not present.

In the rush to implement TLS everywhere, and thereby secure the internet from the evildoers, minority use cases like onion routing have been forgotten about and there isn't a clear solution if you want to inhabit both worlds.

As a workaround I've added a settings screen for the XMPP app within Freedombone which allows TLS authentication to be strictly enforced or not.

Matrix addendum

There has been a recent talk about Matrix at FOSDEM 2019 in which it's said:

As of Matrix 1.0, we require homeservers to present a CA-signed TLS certificate

So very much the same problems are going to apply to Matrix on onion addresses quite soon. Probably the version of Matrix on onion-only versions of Freedombone will need to be modified in order to federate, and will be non-compliant with the spec. If that's infeasible then it might be that Matrix on onion will only be non-federating, which would be disappointing.

Addendum addendum

It looks like Matrix will be ok after all. In the recently published federation API it says:

The TLS certificate provided by the target server must be signed by a known Certificate Authority. Servers are ultimately responsible for determining the trusted Certificate Authorities, however are strongly encouraged to rely on the operating system's judgement. Servers can offer administrators a means to override the trusted authorities list. Servers can additionally skip the certificate validation for a given whitelist of domains or netmasks for the purposes of testing or in networks where verification is done elsewhere, such as with .onion addresses.