Freedombone Blog

Freedom in the Cloud

Epicyon: The case of the missing timelines

On other fediverse servers you have a local and federated timeline, and when I first started on the project I began implementing that. But because it was beginning to get complex I was wondering whether these timelines are strictly required.

As far as I can tell from the ActivityPub specification the local and federated timelines aren't part of the spec. Instead you only have inbox and outbox, like email. It turns out that those timelines are just a convention carried over from StatusNet/identica originally.

Not implementing those timelines seems like an improvement. There is perhaps some loss of discoverability, but there's a much bigger gain in control over what ends up on your timeline and what gets written to disk storage. If you're concerned about the potential for illegal content which you havn't signed up for to get onto your server then doing it the inbox/outbox way gives a lot more confidence that you're remaining inside of the legal boundaries.

Mitigating the Griefers

Griefers are a hazard of being on any kind of social network, or blog if it has comments enabled. So in Epicyon I've used a few methods to mitigate annoyances.

Big messages

The easiest way for someone to do a denial of service would just be to send a gigantic post. Hundreds of megabytes or larger, and have your server clogged up trying to process it. Most often this kind of problem is mitigated by the web server configuration, but in Epicyon there's also a maximum overall message size of 20K. That includes all the json formatting.

http signatures

This is one of those things which is really a fediverse standard, but isn't in the ActivityPub specification. Combining this with permanent signing keys gives a strong assurance that messages are coming from the account you think they are.

Adversarial instances can try to do blind key rotation and pretend to be someone else, but since public keys are only fetched once they're not going to succeed and messages from accounts doing that will be rejected by the signature check.

Blocklists and federation lists

Usually the most controversial aspect of the fediverse. Fights over who is blocking who are frequent. In Epicyon blocking can be global to the instance and also local to particular accounts. Global blocks override account level ones. Federation lists are the opposite, in which you are choosing to only federate with specified other instances. That can be useful if you wanted to deploy a fediverse-like system in a company or school.

Hellthreads

A hellthread is when someone mentions you in a message containing a very large number of other mentions. In 2016 when I was running GNU Social this happened quite often. Even an upper bound of 20K is room for a lot of mentions. In Epicyon there's a configurable threshold for the maximum number of mentions. Anything above the threshold and the message will be rejected.

Emoji flooding

Similar to hellthread mitigation. An adversary can simply send you posts packed with emoji. So there's a threshold for the maximum number of emoji which a received post can contain.

Follower approvals

This is part of the ActivityPub specification and is optional. Sometimes also called "locked account". Being able to approve the people who are following you can avoid tears later. In Epicyon if follower approval is enabled then you can just select the link to the profile of the request and see if their timeline makes sense. Have they made any recent posts which are interesting? Is their timeline full of chuds using dog whistle catchphrases? Are they being followed by or interacting with spooks or neo-nazis?

Driveby DMs

In Epicyon you can also restrict incoming DMs to only people that you follow. It's a feature blatantly copied from Twitter and is intended to mitigate the driveby griefer problem. If you're not interested in having random chuds from the interwebs send you their latest ALLCAPS hot take about why they are now convinced beyond reasonable doubt that the Earth is flat then this can save you time and disk storage.

The Reply Guy

Constantly replying to a message long after the point at which it made any sense to do so was a common griefer tactic in the past. So in Epicyon there's an upper limit on the number of replies a post can have. The reply guy won't be able to send you his 100th sealioning sermon about why you need to immediately provide him with painstakingly researched evidence for some earlier flippant remark, cited in the peer-reviewed academic journal of their choosing.

Word filtering

If adversaries always use common catchphrases, or if you just have zero interest in certain politicians or celebrities, then these things can be added to the word filter.

Snooze

Maybe someone is not deliberately griefing you but they're just having a bad hair day. You don't want to unfollow or block because they're mostly ok. In this situation you can hit the snooze button and not hear from them again for 24 hours. Their posts won't be deleted, just made invisible for a while, and after the time is up you could go back to see what they were ranting about yesterday if you were thus inclined to do so.

Mute

Mute is something quick and easy you can do to not show the content of an individual post. So if some un-CW'd photo is annoying you then you can quickly remove it from the timeline.

Epicyon Shared Items Timeline

Fixed some bugs in the shared items system and have added an instance-wide shares timeline. This allows you to view and receive notifications for the latest things being shared on your instance.

Shared items is a Freecycle-style moneyless sharing system intended for the users of an instance. There is limited visibility of available shares other than to logged in users of the instance, so this follows the usual semi-opaque model. Outsiders will be able to get some idea of the kinds of things being shared, but not full access to the list, nor the ability to do arbitrary searches.

A button allows you to send a DM to the person sharing an item to make inquiries about it. Selecting the image shows you the full sized photo of the item.

Unlike a money based system of exchange there is no attempt to hide the social relationships which are involved behind a currency abstraction.

This functionality was inspired by the earlier Sharings plugin for GNU Social, made by a group called Las Indias.

All the banners we had flown for decades: distributed networks, free software, the globalization of the small… were producing a change in ways of producing wealth and knowledge in which the center was no longer in nations or in big businesses, but rather in small groups and communities that are empowered by a new knowledge commons
Shares timeline of Epicyon

Epicyon Calendar

Going beyond the usual functionality of fediverse servers, calendars have now been added to Epicyon. This is part of the effort to add features useful for organizing social events.

When creating a new post you can now optionally add a date, time and place description. The information gets attached to the post as a tag, using the ActivityStreams Event and Place activities.

There is now a calendar icon which then shows the current month.

Events posted by people you follow will show up there, and selecting particular days then gives you a list of events. If you just want to create reminders for your own use then you can send a DM to yourself containing a calendar event.

Epicyon calendar

This makes organizing events very simple, and you can use message scopes to set up public or private events.

Users of Zot based networks will be yawning at this stage, because this sort of functionality has existed since Friendica, but as far as I know it's new within ActivityPub based systems.

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.

Fediverse debrief

I'm going to take time out from the fediverse for a while. It's not that I've been "cancelled", although the level of hostility recently has been exceeding my personal comfort zone and becoming comparable to Twitter.

A critical design problem of this type of system based upon the ActivityPub protocol seems to be that there isn't any granular control over who you associate with or on what terms. It means that adversaries have unlimited potential to reply on your posts or send menacing DMs. Of course it's easily possible to block them, but the sheer volume of this problem recently means that it becomes like a cat and mouse game, or a game of whack-a-mole.

So it's time for me to step back and think about whether ActivityPub is useful as a method of public communications, and whether I ought to be recommending systems in which the user doesn't have much control over who they associate with other than follow or block. Maintaining an increasingly large blocklist and the amount of research which that requires seems unrealistic.

As an analogy from the past, I abandoned trying to support blog comments for similar reasons. The amount of spam became too much to manage, and automated methods such as CAPTCHAs or cryptic questions failed to prevent it.

For now I think the Zap or Hubzilla approach is better, although there are far fewer users of those systems. With something like Zap it is reasonable to expect that the first time self-hoster could have a good experience on the system, rather than immediately being bombarded by communications which they havn't chosen to opt into.