Your Data. Your Server. Your Place.

Freedombone is a home server system which enables you to run your own internet services, individually or as a household. It includes all of the things you'd expect such as email, chat, VoIP, web sites, wikis, blogs, social networks, media hosting and more. You can run Freedombone on an old laptop or single board computer. No ads and no built-in spying.

Epicyon on i2p

The Epicyon ActivityPub server is now able to be installed on i2p addresses (aka eepsites). This means that it's now possible to run fediverse instances in a purely end-to-end encrypted peer-to-peer mode.

i2p is a bit slower than using a Tor browser, so don't expect rapid page load times. Be prepared for a leisurely pace of events. Get ready to drink coffee and stare out of the window, similar to dialup internet in the 1990s for any older hackers who still remember that. As a practical example, the inbox timeline which takes a couple of seconds to refresh on the clearnet in Firefox might take 10 seconds for an onion instance in a Tor browser or 15-20 seconds or longer on an i2p instance.

Within the deploy directory there is a script called i2p which can be used to install an i2p instance on Debian or Arch/Parabola. With some modifications to package names it could be adapted for other distros.

To access i2p sites use an ordinary browser, like Firefox, and within preferences/network select manual proxy and set http to 127.0.0.1 port 4444 and socks5 to 127.0.0.1 port 4447. Also turn off DNS via HTTPS if that is enabled. Then your i2p domain name should resolve. Unlike in a Tor browser, when in this proxied mode you won't be able to access clearnet sites, only i2p ones.

When not running on an ordinary domain name there are also limits to federation. Instances on i2p domains will typically only federate with other i2p instances. Familiar instances are typically not set up to use i2p and so won't federate. So on an i2p instance don't expect to be able to federate with mastodon.social.

How useful is a peer-to-peer fediverse?

It really depends on your situation. The obvious advantage is that servers aren't needed and you get end-to-end security without any additional coding effort and without needing to rely upon dodgy certificate authorities or DNS/ICANN. The client/server model does have some advantages though, since the server and its admin provide a rallying point around which to build a community with common interests and shared moderation. This could still happen in the peer-to-peer model though, because there's nothing to stop each peer having more than a single user account. So interesting semi-server hybrid architectures are possible.

Relaying and Hashtag Federation

I just saw the talk about hashtag federation in the fediverse and since I havn't written anything on this topic here are my current thoughts.

I think relaying of posts, in the style of an email open relay, is probably a bad idea. It's probably a bad idea in the fediverse for the same reasons that it's usually a bad idea for email. The most obvious issue is that it easily enables spam. For example, suppose there was a hashtag for a currently urgent event. A spammer could then just flood that hashtag with ads, or a political adversary could post random garbage with the hashtag attached in order to flood out the signal with noise and make it less likely that people will pay attention to that topic.

The other issue is post integrity. Usually this is ensured by a http signature, but if a post is relayed then how do we know that the post stored on the relay is the same as the original? An evil relay could alter public posts to deliberately create flame wars and instance blocking.

So I think relaying of posts and hashtags could create more problems than they solve. In the scenario mentioned in the talk you may still get to know what's happening in a protest because people you follow will be boosting posts with the hashtag. Boosting becomes a decentralized way of distributing hashtags around between instances, without breaking the integrity checks via signatures and directly following the chain of trust from one person to another. In the relay model you need to somehow trust that the relay is not evil and it becomes too easy for bad actors to try to influence what people are thinking about a topic.

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