Freedombone Blog

Freedom in the Cloud

Advice to Jack

Dear Jack,

You don't need to ask Elon Musk how to fix Twitter. Elon may know some things about rockets, but aside from that he will only give you bad advice. He is not the average Twitter user and doesn't experience what most of your users are experiencing.

I am glad that you have come to me for a second opinion. I appreciate you taking time out from your busy schedule. Giving all those fascists blue ticks must take up a lot of your time. So here's what you need to do:

First, take a long hard look at your bank account and any other assets which you may have. Ask yourself "can I live modestly on this for the next few decades, or indefinitely? Do I personally have enough?". I think I know what the answer will be. Then ask yourself "do I really need the money, or am I embarked on a more general project to do something for the world?". To "put a ding in the universe", as the late Steve Jobs put it.

It's going to be the latter.

So how to improve the world with Twitter as a starting point. You won't be able to fix any of the existing problems with AI. That will only make the situation worse. Turn Twitter into a set of fediverse instances. You could do it by country/state (twitter-uk, twitter-us-ca, etc) or by topic, or both. Country is probably easiest, since the user migration can be automatic. Go all-in on ActivityPub. Send some people to W3C to fix the protocol specification to properly include all of the features actually in use in the current fediverse. You don't need to be a genius or invent anything new. It's all been done for you already. All you need to do is produce a nice document which is easy to read, with examples. Then turn your company into a non-profit foundation which maintains the instances and contributes to the evolution of open standards.

You may be wondering how this solves the "fake news" or bot armies problem. It doesn't. But if you implement the federated standard with all of the moderation controls, and let admins do their thing, then you will find that the bad actors become contained. They lose their global reach and ability to mobilize rapidly. In a federated system the problems that you're trying to fix become more tractable. Users can migrate around to whichever instance suits them and there's a self-organizing "invisible hand" type of effect. New spinoff instances will appear and some of those you originally set up may fail, but that's ok.

You can spend the rest of your days as an ambassador for open standards, an open web and instance governance best practices. This is how you put a ding in the universe. If you just carry on the way you are doing things now then you'll go down in history as "the guy who helped rig elections" or "the guy who helped give nazis a platform". I'm assuming that's not the sort of legacy you'd prefer to leave.

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.