Freedombone Blog

Your Data. Your Server. Your Place.

Patches over the Fediverse

Epicyon now has the ability to post and receive git patches. If you make a commit to a git repository and then use the format-patch command and paste the result into a new post in Epicyon then you can send patches to other people over the fediverse. On the receiving side they will appear shown in a monospace font. This only works if you include the name of the project within the CW/subject line and on the receiving side the project name needs to be added within the profile settings (i.e. you need to opt in to receive patches for a project).

When a patch is received it will be put into a patches subdirectory within the users account directory. This can then be applied in the old-fashioned manner, or you could have a script do something with the incoming patches.

So this provides a non-centralized way of receiving git patches, other than via email. There is however a small problem. The character limit on most fediverse instances isn't big enough to be able to paste anything other than the most minimal patch. So that's a fundamental obstacle.

Why bother with the fediverse as a way of transferring patches? The traditional decentralized way of doing software collaboration, which is still used by the Linux kernel, is via mailing lists. But for that workflow to perform well you really need to be on top of your email client with your procmail rules tweaked to perfection. Not everyone is at this level of ubergeekdom. Also keeping spam out of mailing lists can become time consuming and demoralizing. By contrast leveraging the existing moderation and http signature features of the fediverse means that many of the problems with the traditional development model can be averted.

I've also been reading the ForgeFed specification. It doesn't look as if this has had much uptake, and reading through the various issues I can see that there have been years of argumentation with very little implementation. Crucial features such as pull requests appear to have been forgotten about entirely.

So I might divert some effort into making a git server which is genuinely decentralized but doesn't depend upon using mailing lists. I could use the existing ForgeFed framework and add in the parts of the spec that are missing. This would help with other projects, because it has to be admitted that my current collaboration workflow is less than ideal. People can make pull requests on GitLab mirrors, but then there isn't any straightforward way to get those upstream to my own server.

Epicyon 1.1.0

Like a husky emerging from a snow drift Epicyon ActivityPub server version 1.1.0 is thus released onto the unsuspecting interwebs.

This version contains numerous changes from 1.0.0, some of which are as follows:

  1. Much faster timelines
  2. Works on onion addresses without https
  3. Media timeline and media instance option
  4. Better support for different image formats
  5. Support for video and audio
  6. Calendar
  7. Hashtag swarm
  8. Better federation compatibility with Pleroma
  9. More languages supported
  11. Snooze and mute
  12. Better handling of avatar images
  13. More emoji
  14. Better layout in non-graphical browsers, like Lynx
  15. Image blurhashes are optional

The calendar feature, which allows you to specify a date and time on a post, isn't yet standard across the fediverse but it uses ActivityStreams vocabulary and enables easier organization of events.

It has been tested on a Beaglebone Black and so can run on systems which by today's standards have very little memory. This should help towards the goal of getting more people or groups to run their own fediverse instances.

Going Audiovisual in ActivityPub

With some amount of wrangling, video and audio attachments now work in Epicyon.

screenshot showing embedded video clip

I've set the upper limit to 30M, which should be enough for short videos and podcasts. Supported formats are mp4,webm,ogv,mp3 and ogg.

One thing to keep in mind is that metadata isn't removed from these uploads, so if they contain any geolocation you might want to remove that manually beforehand. Whether metadata should be removed from media such as mp3 is debatable, since it might also be significantly useful. Perhaps that could be a configurable option.

Epicyon 1.0 release

Announcing the first release of Epicyon. This is an ActivityPub compliant server, supporting both S2S and C2S protocols and which can federate with Mastodon

Epicyon screenshots

All the basic functionality is in place, such as making posts, scopes including direct messages, blocking and filtering, content warnings and moderator functions. It's implemented in a manner similar to an email MTA with posts being stored as files in directories rather than within a database.

Why yet another ActivityPub server?

There are many ActivityPub servers out there but there are currently really only two which are suitable for general social networking rather than particular niches: Mastodon and Pleroma. Other systems like Friendica may federate with ActivityPub instances, but internally use their own protocol [correction - it does natively support ActivityPub among other protocols]. Most of the server code on Github or Gitlab is either very early stage development or abandonware, and it's expected that abandonments happened because the developers soon realized that it was a more involved task than the few available tutorials imply. Bigger than a weekend hackfest. Mastodon is ok but not well suited for running on low power hardware such as ARM boards. Pleroma is more suitable for self-hosting, but its limitations were becoming increasingly obvious when confronted with more serious levels of adversarial activity.

Also there were questions of depth versus breadth. Traditional social networking was about casual gossip and posting news links, but perhaps they could also be organizing tools to build communities with more depth and resilience to them. Beyond the state and the corporation, better ways to organize are needed if existing institutional intransigence is to be treated as damage and routed around.

Beyond ActivityPub

Some extra features have been implemented which go beyond the current ActivityPub spec. Shares is a system for exchange of physical items, similar to freecycle or bartering. The idea is one of local non-monetary exchange and the development of pooled resources between trusted mutuals.

Skills allow you to publicly indicate what skills you have. Combined with a search function this perhaps makes it a little easier to search around within a trusted group for people to form a team with the needed combination of skills. People can of course indicate skills which they don't possess, but the ordinary mediations of a social network (blocking, filtering, peer pressure, etc) should make it feasible to remove dishonest actors.

Moderation features

As the internet and social networking mature it has become apparent that the threat to good order is not anonymity or even pseudonymity but unmoderated spaces. Rather than enabling maximal freedom as intuition might suggest, unmoderated spaces instead create a pressure cooker of maximal tyranny in which bad actors can carry out a reign of terror. Neither corporations like Facebook nor government regulations can create healthy communities merely by decree. People have to learn to govern themselves within the online space.

Epicyon includes moderation functions whereby the admin can assign other people to act as moderators enforcing the terms of service, which can be customized as needed. Members can also report suspicious posts to the moderators.


Emoji are of course implemented using the OpenMoji icons. It's also easy to add new emoji to the list. Unlike some other social network interfaces there is also the ability to search for particular emoji rather than trawling through a gigantic list.

Some limitations

Currently attachments can only be images. There isn't yet support for video or audio, though that may come in later versions.

The Mastodon API is also not implemented and this means that you can't currently use Epicyon with Android apps such as Tusky. This also might be added in a later version.

The familiar timelines (local, federated, etc) which originated from StatusNet also aren't implemented. ActivityPub only defines inbox and outbox, just like email, and that model has been stuck to. This may be easier to understand for people new to the fediverse, since most people already have a mental model for the way that email works.

There is currently no push mechanism between the server and a web browser. Instead it performs a primitive meta refresh every few minutes. This is obviously not ideal for mobile, and may be improved upon in future.

Messing with ActivityPub

Recently I've been trying to implement the ActivityPub protocol. I wanted to get more of an understanding of what the issues are with it, and see if I could implement a server from scratch. Mastodon is ok, but too resource intensive for my use cases. The filtering system of Pleroma generally works well, but I was still struggling to keep bandits out of my inbox and it was becoming too much of a chore. Self-hosting is supposed to require little to no maintenance if it's done right.

If I'm to remain in the fediverse at all then what I'm looking for is something which requires minimum RAM and storage space. Where the database size has a strict maximum upper bound. And where I can be confident about what (or who) is or isn't getting onto my server. I searched around for existing projects which might fit the bill, other than Mastodon or Pleroma. GNU Social and PostActiv are still around and they were a good solution a few years ago. But I think the state of the art has moved on and something like GNU Social isn't geared up to handle the adversarial situations which now exist. It was designed for a gentler world of Free Software developers exchanging cycling trip photos and commandline tips. Now that there are a million or more fediverse users it's a different game entirely and the blooming buzzing confusion of the crowd requires some taming to be humanly interpretable.

So I may spend the next period of time developing a minimal fediverse server, equivalent to an email MTA. Maybe it won't work out and there will be some show-stopping reason why this is a bad idea, but in principle it seems like a tractable piece of work. On top of all the usual features it would also be interesting to experiment with adding organizing features and also something comparable to the old GNU Social Sharings plugin for bartering and freecycling.

I have some initial code here. Of course, it had to be named after a species of extinct megafauna. It's highly experimental and mostly just a bunch of unit tests, so I don't recommend that anyone use this for any practical purpose right now.

In case you were wondering, the next version of Freedombone will be out soon although I don't expect it will have any fediverse servers. In my estimation the existing software is too unsafe and too high maintenance for an install-and-forget type of system.