Fedi... what?

Are the feds coming?! Nah, I’m talking about the fediverse.

As you might know (or not), I’m trying to move away from the fast-paced, algorithm-driven part of the internet. Besides creating this blog, I’ve also joined some fediverse instances.

I realized I don’t really know how the fediverse works, and I figured I can’t be the only one.

What I didn’t realize is how deep this rabbit hole goes.

Anyway, here we go:

What is a fediverse?

A fediverse is a decentralized social network consisting of multiple platforms, such as Bluesky and Lemmy, that can interact with each other. There are also instances within a platform.

The instances communicate over a shared protocol, similar to how computers talk to each other over the internet. But instead of computers, they are instances of, for example, Bluesky - and here’s the neat thing: instances of different platforms can interact with each other as well.

Most commonly, instances interact within the same platform. It’s all up to the instance. Some Mastodon instances I’ve encountered are: fikaverse.club, tech.lgbt, social.s31bz.com, and mastodon.art.

Anyone -person or company- can create their own instance of a social platform, either for themselves to get a cool handle or for their community/company/location/cult/whatever. This also makes it possible for each instance to set up its own rules and guidelines. So one instance can block another instance, for example.

You can find a bunch of fediverse platforms on the Wikipedia page.

How does a fediverse actually work then?

So, it’s all about these protocols. Some you should already know are the Internet Protocol (IP) and Simple Mail Transfer Protocol (SMTP). The protocol that most fediverses use is ActivityPub, which includes a family of protocols, data models, and an architecture consisting of two protocols:

• client-to-server (C2S) for users to create and modify content.
• server-to-server (S2S) for delivering notifications and content to other servers.

The three main data types are:

Objects are the most common data type and can be images, videos, or more abstract items such as locations or events. They represent the content itself.

Activities are actions that create or modify objects. For example, a ’like’ on a post.

Actors represent an individual, a group, an application, or a service (aka. platform), similar to a traditional account. They are the owners of objects and the creators of activities. All actors also have an inbox and an outbox, similar to how email works.

     ┌──────────────┐
     │    Actor     │
     └──────────────┘
       ↓          ↑ 
      POST       GET
       ↓          ↑
   ┌───────┐ ┌────────┐
   │ Inbox │ │ Outbox │
   └───────┘ └────────┘
       ↓          ↑
      GET        POST
       ↓          ↑
     ┌──────────────┐
     │ Other Actors │
     └──────────────┘

It’s all about the inbox, outbox, bullshit

Writing that title made me think of Break Stuff by Limp Bizkit.

Remember, Actors are entities like individuals, groups, or services that represent accounts and can create activities. Clients are software tools (not Actors) that users employ to interact with servers, and servers manage the infrastructure for Actors without being Actors themselves.

• A server can POST to an Actor’s inbox to deliver a message, which is restricted to server-to-server federation for cross-instance communication. This ensures the secure delivery of activities between servers. This is the core of federation.
• A client can GET from an Actor’s inbox (e.g. your own) to retrieve and display messages as part of client-to-server operations, such as viewing a social feed. This allows users to access incoming activities for their Actor.
• A client can POST to an Actor’s outbox (e.g. your own) to publish messages, which are handled through client-to-server interactions. This enables Actors to create and share activities with the network.
• A client or server can GET from another Actor’s outbox to view posted messages (if authorized), involving client-to-server or server-to-server protocols. This supports discovering and accessing public or permitted activities from other Actors.

You can read more at w3’s page on ActivityPub.

Other protocols in the fediverse

The most notable protocol aside from ActivityPub is the AT Protocol, which is developed by Bluesky. It started as a research project at Twitter but was set up as its own independent company from the beginning. After Elon Musk bought Twitter and severed the ties, BlueSky was created as a proof of concept, and the project continued to thrive.

The biggest difference between the AT Protocol and ActivityPub is that the AT Protocol consists of microservices, while ActivityPub typically hosts both user data and the application on the same server as a monolith.

Some other, less prominent protocols in the fediverse are Nostr and Disaphora. But for those, you’ll have to dive into the rabbit hole yourself.

BridgyFed

To interact across different protocols, Bridgy Fed is used. With this, you can bridge between ActivityPub, AT Protocol, personal blogs, RSS, and Pinhole, among others. It’s not yet 100% bidirectional, but the developers are always striving toward it.

Why should we use fediverses instead of mainstream social media?

There are certainly a few pros and cons, and personally, many of the pros outweigh the cons.

Pros

• Each instance can have its own rules and restrictions, using blocklists to curate content for users.
• You are not locked into interacting within a single platform or instance.
• Most platforms haven’t implemented algorithms for curated feeds; instead, you see what you follow or whatever is in your instance. Why is this good?
  • You don’t get stuck doom-scrolling as easily.
  • You spend less time on things you couldn’t care less about.
• The platform doesn’t sell your data.
• You can choose an instance and platform that align with your values.

Cons

• Sharing links between different instances through other platforms can be a struggle since you can’t log in to their instance, so you need to convert the link to your instance.
  • Suggestion for improvement: Add a small text field or dropdown menu where you can change the instance while staying on the same post.
• Not all platforms are “good” just because they are federated. For example, Threads by Meta is part of the fediverse, but are they truly part of it, tho?
• ActivityPub can be hard to implement properly. When implemented improperly:
  • It can cause unintentional DDoS attacks on other websites and servers due to the decentralized nature of the network.
  • It can cause replies and parts of threads to disappear and can also show incorrect statistics on posts, etc.
• There is currently no official support to migrate an account from one instance to another, but it is possible through unofficial tools and guides.

Fedipact

The Fedipact is a pledge against Threads and Meta to block all content from them. If you have read this far, I assume you understand why, and I won’t go into details.

Instead, check out this comment section on Hacker News or go directly to the blogpost on Daring Fireball.