The Mutt email client which is installed by default on Freedombone now supports the X-Face email header. This is a very old standard for email avatars from the 1980s. It's a blatantly geeky, almost easter egg, type of feature. Supporting standards like this is fun because they're so anachronistic that they are able to fly under the radar of the modern internet. Hence you could possibly exchange subversive ultra low resolution avatar iconography without that being especially obvious even when emails are entirely sent in the clear.
If you ssh into your Freedombone server then there is now an option on the control panel to add an avatar image, and this can either be an image file or a URL. It will then get converted to a binary 48x48 image and attached to any email sent from the Mutt client. You may need to experiment by sending emails to yourself to obtain an avatar which looks at all intelligible. Obviously at such a low resolution any details get lost.
If you see an X-Face header in the Mutt email client you can then press Escape and then the f key to show it .
I did think of also adding this to webmail and the members screen of the web interface, but I don't think that would be a good idea. Since Freedombone is primarily aimed at more mainstream uses the typical expectations around the image quality of avatars will be vastly higher than X-Face can provide, and would merely be a source of frustration.
There was very little digital photography or scanning in the 1980s (fax machines would be about as close as it got) and so in the time frame when X-Face was invented people were probably making hand-drawn avatars using a bitmap editor, or even just on graph paper and then doing the calculations to convert to bytes manually. You could get imaginative and draw a 48x48 grid on acetate and then overlay that onto a chemical photograph of your face to obtain a crude digitization. Especially considering the tight bandwidth constraints and high telecoms costs in the 1980s, adding avatars would have been an extremely luxurious feature.
The plan for this year is to add more game apps to Freedombone. The intention isn't to turn the system into a gaming platform, but running a game server is one way that people can learn about self-hosting in a more accessible and fun way. Unsurprisingly there aren't all that many Free Software game servers out there. But there are a few, and some of them are packaged for Debian. Recently I've added a couple more as Freedombone apps. Neither of them are playable on mobile.
Crossfire is a rogue-like role playing game almost as old as AberMUD, but still appears to be actively developed nearly three decades later.
Flightgear Multiplayer Server is high bandwidth according to its installation instructions, but if you're only using it with a few clients on a local network then I expect it would be fine for practising formation flying.
Within Freedombone the Cryptpad app has been updated to the latest commit, and it now allows you to create accounts and potentially have permanent "pinned" pads on the server. Previously account creation was deliberately disabled because this is an open system where anyone on the internet can access your Cryptpad site and allowing the whole internet to sign up is probably not a good idea on a small server with finite resources intended for use by a few people only.
I was looking for things like registration limits within Cryptpad, but didn't find any setting for that. I think the reason is that with Cryptpad and many other web apps they're designed such that the intention is that millions of people will sign up on a big centralized cloud server system. It's how they monetize the whole thing (notice the Cryptpad pricing and how that works). So the people who are writing the software just aren't occupying a small tech kind of mindset where you want to keep things limited to a few users. It's a dichotomy in web software design which I've often encountered.
Another feature added is that if you turn on signups for Cryptpad within the Freedombone web interface then they will turn off again automatically within a few days. This is to try to mitigate the "I forgot to turn it off and now my server is no longer working because a spambot has created a million accounts and used up the disk space" scenario.
I notice that the Pleroma project (another ActivityPub server) has been having trouble with spam, and there have also been earlier spam problems with Mastodon instances. They've mitigated it by having a captcha by default. Personally, I don't like captchas. I don't like them mainly because I can't solve them (the ones with heavily distorted text). As far as captcha systems are concerned I am a robot. Beep boop.
So how does Epicyon deal with spam?
In its design ActivityPub is quite similar to email, and that means it can potentially suffer from similar problems. There are a few ways that fediverse instances in the last couple of years have dealt with this.
The main one is http signatures. Without getting into the details of http signatures as a cryptographic mechanism this basically gives a reasonable assurance about which account a post is coming from when it gets delivered. But that on its own isn't enough. An adversary can potentially generate arbitrary numbers of separate accounts at electronic speeds.
An additional mitigation commonly used has been registration limits. On a public instance you might open new registrations for a limited time or for a limited number of new accounts and then close it again and allow time for the newcomers to settle. The settling time tends to avoid admins becoming overwhelmed by newbie questions, trolls or spam floods. This seems to have worked quite well, and Epicyon also has this available. You can set registrations to be open and then also specify the maximum number of new registrations. By default new registrations are allowed and the maximum is set to 10. In a Freedombone installation with the Epicyon app installed new registrations are closed and only created via a command in the background when new members are added from the admin screen.
Epicyon also has quotas, with a maximum limit on the number of posts which can be received from an account or a domain per day. So if there's a rogue instance sending out a lot of spam or if one of your friends accounts gets hijacked then the maximum rate at which posts can arrive is contained.
Then there is the infamous DDoS scenario. Suppose that there are a million bad instances out there on different domains and they all send one spam per day. In this case it's down to the firewall, and Freedombone only allows a limited number of simultaneous connections on the https port.
Epicyon also does things in a way which makes life difficult for spammers. As a general rule you only see posts from people that you're following. There is no public or federated timeline. And there is no relaying of posts going on either. To a large extent what you see is what you get, with no additional stuff from random accounts you're not interested in. So unless you are following a spam account they may have difficulty getting into your timeline. An extra feature which is off by default but which can be turned on if you need it is to only receive DMs from people that you are following.
It should also be said that Epicyon isn't designed to run large public instances with thousands of accounts. It's intended to support about ten accounts at the upper limit, for self-hosting or small groups. At large scale Epicyon would probably perform poorly, and this is another reason why it would be unattractive for use by spammers. A Small Tech approach has advantages which would otherwise become headaches for projects fixated upon scaleability.
There is now a Freedombone image for the Rock64 single board computer. They're fairly cheap and sufficiently powerful that I've been using one of these as a desktop machine for the last year without any major problems. The Rock64 has an A53 processor which doesn't do speculative execution and so is not vulnerable to an entire category of possible security problems.
There are two images available here. freedombone-main-rock64-arm64.img.xz is the clearnet version and freedombone-onion-rock64-arm64.img.xz is the onion version. It's recommended that you install to an SSD and then connect it to the USB3 port with a USB3 to SATA adapter cable. You will also need to install this boot utility which changes the boot order so that the Rock64 can boot from USB.
At the recent 36C3 congress there was a talk about the Freedombone project for the first time. It's in German and there aren't any English translations but since I've given a similar talk in Manchester earlier in 2019 I know roughly what's being described. The slides for the English version of the talk can be downloaded here.
Freedombone has been going for quite a while now, but having someone other than myself doing a talk about it at a CCC event where there are likely to be people who are interested is some kind of significant milestone for the project.
Every year I review what projects I'm working on and try to assess whether they're still relevant and worth continuing with. Technology moves quickly and what may be highly relevant one year may be technically and/or socially obsolete the next. But in the case of self-hosting projects - of which Freedombone is one - this still seems more relevant to the current time and the likely near future than at any point in the past. If anything, the problems which Freedombone tries to overcome are only becoming more acute and more conspicuous to the average internet user.