The Fediverse

The Fediverse is a collection of independent servers communicating via a shared protocol. The primary protocol is ActivityPub. It standardises the transmission of text, images, and user states across disparate hardware. This infrastructure eliminates the central authority of a single corporate entity, distributing server costs, moderation policies, and data ownership across the network participants.

The Nigerian digital landscape currently lacks native ActivityPub infrastructure. Users operating from Nigeria rely exclusively on foreign hardware. This manual establishes the structural architecture of the Fediverse, defining the specific hierarchy required to operate within it and detailing the operational differences between its software platforms.

The Structural Hierarchy

The network organises into three distinct tiers: Domains, Instances, and Communities.

Domains represent the foundational software platforms. Mastodon, Lemmy, and Pixelfed are Domains. They define the data structure–whether the platform processes micro-blogs, threaded forum discussions, or image galleries.

Instances are the physical or virtual servers running the Domain software. A Domain is a blueprint; the Instance is the deployed reality. Users register accounts on Instances, not Domains. The Instance dictates the moderation policy, the data storage limits, and the exact version of the Domain software in operation.

Communities exist exclusively within specific Domains–primarily Lemmy and PieFed. They are categorised data hubs. An Instance hosts the overall platform, while Communities segment the users and posts into subject-specific architectures.

The Protocol Interoperability Friction

The ActivityPub protocol enables cross-Domain communication. A user on a Mastodon Instance can follow and reply to a user on a Pixelfed Instance. The mechanical reality of this interaction is highly flawed.

Interacting across Domains requires heavy protocol translation. When a Mastodon Instance processes a post from a Lemmy Instance, it attempts to map a threaded, subject-based forum structure onto a chronological micro-blogging interface. The translation strips metadata. Threaded replies flatten into a single chronological timeline. Context is destroyed. Voting mechanics–such as Lemmy’s upvote and downvote system–fail to register on Mastodon, which only recognises ‘favourites’ and ‘boosts’.

Complete functionality requires native accounts within each Domain. To interact with the Lemmy network without data degradation, a user must operate a Lemmy account. Cross-Domain federation is a baseline fallback for visibility–it is not a substitute for native interaction.

The Microblogging Domain

Mastodon is the primary microblogging Domain. It processes short-form text, links, and media attachments. It broadcasts these data packets to followers in a strict chronological feed.

The core Mastodon software dictates specific limitations, leading to the creation of competing software forks. These forks operate on the same ActivityPub protocol but alter the local Instance capabilities.

Glitch-soc is a modified version of Mastodon. It adds local-only posting capabilities, allowing users to broadcast messages exclusively to their Instance without federating the post to the broader network. It includes advanced text formatting options and structural modifications to the user interface.

Hometown is another fork, built upon Glitch-soc. It prioritises localised interaction over global federation. It allows Instance administrators to restrict specific posts from leaving the Instance server, creating isolated digital environments while maintaining the ability to read external data.

Akkoma and Pleroma are lightweight microblogging alternatives to Mastodon. They demand significantly less server hardware to operate. They process data faster but feature brutalist user interfaces and lack some of Mastodon’s advanced filtering tools.

Connecting to the Microblogging Domain requires client software. Users access Mastodon and its forks via dedicated applications. Ice Cubes and Tusky pull data from the Instance via APIs, displaying the feed on mobile devices. The client software handles the interface; the Instance handles the data storage.

The Aggregation Domain

Lemmy structures data as threaded discussions. It is an aggregation Domain. Users submit links or text blocks, and the network ranks them based on user interactions.

The Lemmy architecture introduces the Community tier. A Community is established on a specific Lemmy Instance. Users from any Lemmy Instance can subscribe to that Community. The host Instance stores the original data; subscriber Instances cache copies of the data for local users.

Kbin is an alternative aggregation Domain. It attempts to merge the microblogging interface of Mastodon with the threaded structure of Lemmy. It allows users to post short-form microblogs alongside long-form threaded articles. This dual-structure creates database bloat and increases the difficulty of cross-Domain federation.

Client applications for the Aggregation Domain include Mlem and Voyager. These applications interpret the nested threading and voting mechanics specific to Lemmy and Kbin, presenting the data efficiently on mobile hardware.

The Visual Domain

Pixelfed processes image galleries. It mimics the interface of centralised image-sharing platforms. It applies filters, organises media into albums, and federates these images across the ActivityPub network.

PeerTube processes video data. It operates a peer-to-peer distribution model. When multiple users watch a video on a PeerTube Instance, the software utilises their local network bandwidth to share the video data among them, reducing the load on the host server.

Infrastructure and Deployment in Nigeria

The complete absence of Nigerian Fediverse Instances creates a dependency loop. Nigerian users generate data that is stored and monetised by foreign hardware operators. Establishing sovereignty requires local deployment.

Deploying an Instance requires a Virtual Private Server (VPS), a domain name, and an object storage bucket for media assets. The administrator configures a reverse proxy–typically Nginx or Caddy–to route incoming traffic to the ActivityPub software. The Instance stores user data in a PostgreSQL database.

Instances scale through horizontal federation, but database management dictates survival. Every time an Instance user follows an external account, the local database must process and store the incoming data packets from that external Instance. Without aggressive caching limits and automated media purging, the local database will exhaust the server’s storage capacity.

Security must focus on the infrastructure level. Dependency chains in software deployment present vulnerabilities. Relying on bloated package managers introduces supply chain risks. Administrators must utilise system-native build tools and restrict network access to the database layer via strict firewall configurations.

Moderation is a mechanical process. Spam and malicious data propagate through federation. The administrator executes server blocks (defederation) to sever the connection between the local Instance and the offending external Instance. This drops all incoming packets from the blocked server at the protocol level.

The Mechanical Failure of Cross-Domain Communication

The assertion that the Fediverse is a single, unified social network is a marketing fiction. It is a collection of disparate software architectures forced to communicate through a lowest-common-denominator protocol.

ActivityPub operates on a system of Actors, Inboxes, and Outboxes. When a user on a Mastodon Instance publishes a post, the software wraps the text and media in a JSON-LD data object. The Instance server then queries the database for every external Instance where a follower resides. It fires this JSON-LD object directly into the Inboxes of those external servers.

This works efficiently within the Microblogging Domain. Mastodon to Mastodon communication is native. Mastodon to Hometown communication is near-native. The database structures expect chronological, short-form data.

The structural failure occurs when data crosses Domains. Lemmy is an Aggregation Domain. It does not natively understand chronological timelines. It understands hierarchical trees–a root post, followed by nested replies, ranked by numerical scores.

When a Lemmy user comments on a Mastodon post, the Lemmy Instance wraps the comment in an ActivityPub object and sends it to the Mastodon Instance. Mastodon receives the object, fails to comprehend the nested threading context, strips the relational metadata, and appends the text as a flat, chronological reply.

When a Mastodon user attempts to participate in a Lemmy Community, the failure is reversed. Mastodon has no concept of ‘Communities’–it only understands ‘Users’. To interact with a Lemmy Community from Mastodon, the Mastodon user must address the Community as if it were a single user account (e.g., @technology@lemmy.world). The Mastodon software then blasts the reply into the Lemmy Community. The Lemmy software attempts to parse this, but because the Mastodon user cannot transmit an upvote or downvote, their interaction is structurally crippled. The Mastodon user is permanently locked out of the core mechanic of the Aggregation Domain.

To operate effectively across the Fediverse, users must establish separate accounts native to each Domain. A user requires a Mastodon account for microblogging, a Lemmy account for aggregation, and a Pixelfed account for image distribution. Treating ActivityPub as a universal translator destroys data fidelity.

Advanced Domain Analysis: Microblogging

The Microblogging Domain is saturated with Mastodon instances. Mastodon is written in Ruby on Rails. It is notoriously resource-heavy. It requires Redis for job queuing, PostgreSQL for data storage, and Node.js for streaming connections. This hardware requirement creates a barrier to entry for independent operators.

Pleroma and Akkoma solve the hardware bloat. They are written in Elixir. They require a fraction of the RAM needed by Mastodon. An Akkoma Instance can run on a single-core Virtual Private Server with 1GB of RAM, servicing dozens of users.

Akkoma introduces Custom Emoji Reactions–a feature absent from native Mastodon. When an Akkoma user reacts to a post with a custom emoji, the ActivityPub object transmits this reaction. If the receiving Instance is Mastodon, the Mastodon software silently drops the reaction because its database schema does not support it. This illustrates the core problem of protocol fragmentation: advanced features are trapped within specific software forks.

Misskey and FoundKey represent the hyper-interactive branch of the Microblogging Domain. They integrate complex drive storage systems, massive custom emoji integration, and widget-based dashboards. They generate extreme database traffic. A Misskey Instance federating with a standard Mastodon Instance often overwhelms the Mastodon server with reaction data and protocol requests.

Advanced Domain Analysis: Long-Form and Audio

WriteFreely and Plume define the Publishing Domain. They process long-form text. They do not operate on chronological feeds. They structure data as static blogs. When a WriteFreely article federates to Mastodon, Mastodon truncates the text and provides a hyperlink back to the host Instance. The interaction happens on Mastodon, but the reading happens on WriteFreely.

Funkwhale defines the Audio Domain. It is a decentralised audio hosting and streaming platform. Users upload music or podcasts, and the software structures the data into libraries. These libraries federate via ActivityPub. A Mastodon user can follow a Funkwhale library and receive audio tracks in their timeline, but they cannot natively browse the nested albums without accessing the Funkwhale interface directly.

The Nigerian Imperative: Server Sovereignty

Operating within the Fediverse without owning infrastructure is digital sharecropping. Nigerian users are currently generating data that populates European and American databases. The administrators of these foreign instances hold absolute power over the data. They can terminate accounts, purge databases, or sever federation links at their discretion.

To establish digital sovereignty, Nigerian operators must deploy native infrastructure.

Database Architecture and Hardware Reality

Deploying an Instance is an exercise in database management. PostgreSQL is the central organ of the Fediverse. Every text post, every image link, and every follower relationship is a row in a PostgreSQL table.

When an Instance connects to the wider Fediverse, the database balloons. A single user following 100 active accounts on external Instances will force the local server to download, process, and store thousands of JSON-LD objects daily.

Nigerian deployments must prioritise aggressive pruning. Administrators must configure scheduled tasks (cron jobs) to delete cached media and stale posts from external Instances. Without strict retention policies, a 100GB storage volume will fill in weeks.

Security and Supply Chain Isolation

System integrity is paramount. Relying on pre-packaged installation scripts obscures the software architecture and introduces external vulnerabilities.

Administrators should compile software from source or utilize strict, minimal containerization. The avoidance of vast, unregulated package registries–such as the Node Package Manager (npm)–is critical for securing the server environment against supply chain poisoning. Build from the metal up. Verify the source code.

Configure the server firewall to drop all incoming traffic except ports 80 (HTTP), 443 (HTTPS), and 22 (SSH). Isolate the database. Ensure PostgreSQL only listens on the localhost interface. Never expose the database to the open internet.

The Moderation Mechanic

The Fediverse lacks a central authority. Moderation is executed at the Instance level. It is a brutal, mechanical process.

Administrators wield two primary tools: Silencing and Suspending.

Silencing an external Instance hides its users from the local public timelines. The data still enters the local database, and local users can still explicitly follow those accounts, but the data is removed from public discovery.

Suspending an external Instance severs the ActivityPub connection entirely. The local server drops all incoming requests from the suspended server. The database ceases to store its data. This is the ultimate defensive mechanic against spam networks and malicious domains.

African instances must heavily utilize proactive suspension. The global Fediverse is saturated with automated scrapers and malicious actors. Maintaining a functional Instance requires an aggressive defederation policy. Connect only to trusted Instances. Cut the rest off at the protocol level.