Part 1 of The Fediverse Beyond Mastodon. This series is part of the Exploring the Fediverse umbrella. The Federation Across Networks series covered cross-protocol bridges: AT Protocol, Threads, and Nostr. This series stays inside ActivityPub and maps what's already there.

When the 2022 Twitter migration sent people looking for alternatives, Mastodon was the platform in the headlines. For many, it became their entry point to the fediverse, and for some, the only part they've explored.

The ActivityPub network runs software built with different assumptions about resource requirements, interface design, governance, and what federated social networking is actually for. Several of these platforms predate Mastodon. Some were already federating before the W3C spec existed, using protocols of their own design. They adopted ActivityPub later, as the network grew. They all interoperate, but they're built for different people.

Where things actually stand

These numbers come from FediDB, which aggregates self-reported data from instances across the network, as of June 2026. Monthly active users (MAU) reflects accounts that posted at least once in the past month.

*GoToSocial is designed primarily for single-user personal instances, most of which run in private mode and don't expose public stats to aggregators. FediDB records 71 MAU; the true count is almost certainly much higher. Server count is the more useful signal.

‡Misskey family combines Misskey, Sharkey, Firefish, and Iceshrimp. Firefish reached end of support in late 2024; its MAU reflects lingering accounts on instances that haven't fully migrated. Catodon, a smaller active fork by former Firefish contributors, is not yet tracked separately by FediDB.

†WordPress and Ghost ActivityPub MAU figures count active publisher sites, not individual users. WordPress's ActivityPub plugin can expose per-author profiles on multi-author sites, but most installations federate as a single site-level actor. The server counts are the more meaningful signal for these platforms.

Pixelfed, PeerTube, and Loops are covered in Part 2 of this series.

Misskey and the expression-first fork family

Misskey launched in Japan in 2014, three years before Mastodon. It adopted ActivityPub in 2018, becoming a federated platform compatible with the rest of the fediverse while remaining distinct in almost every design decision. It's written in TypeScript with a Vue frontend, backed by PostgreSQL and Redis, and licensed under AGPLv3. It remains heavily used in Japanese-speaking communities, particularly fandom and anime-adjacent circles, where its expression-first design maps onto existing online culture: custom stickers, reaction vocabulary, shared visual shorthand. It had accumulated four years of that feature set before Mastodon existed.

The clearest departure from Mastodon is the reaction system. Mastodon uses a single favorite button. Misskey replaces it with the full Unicode emoji set plus unlimited custom emoji that instance admins can upload. Every post gets a reaction picker. Posts accumulate reaction counts broken down by emoji. The interaction model is expressive by design: instead of a star, you react with whatever fits the moment. Users on other ActivityPub software see reactions as a standard favorite; Misskey users see the specific emoji chosen.

Custom emoji culture runs deeper than it sounds. Misskey instances maintain large libraries (hand-drawn, community-contributed, imported from other instances) and reacting with them is a meaningful part of how communities express identity. The closest analogue is early Slack workspace emoji culture, but federated. The emoji your instance creates can appear on posts across the network.

Beyond reactions, Misskey ships several features that Mastodon has been slow to adopt. Antennas let users build custom keyword-based timelines filtered across the federated network: a live feed of everything mentioning a specific topic, without following every account that might post about it. Channels create local group-like timelines within an instance. Drive gives each user built-in file storage integrated into the posting interface. Quote posts are native. MFM (Misskey Flavored Markdown) adds inline text effects (color, sizing, animation) that go well beyond Mastodon's subset. Character limits are configurable per instance.

The fork ecosystem is genuinely confusing from the outside. The Misskey family splits into soft forks and hard forks. Sharkey is a soft fork: it tracks Misskey's upstream codebase closely, adding moderation tooling, admin roles, and registration controls without diverging far from the core. Staying close to upstream means it picks up Misskey's improvements without maintaining a parallel codebase. Sharkey is the most common migration destination for admins leaving other forks.

Iceshrimp forked from Firefish 1.0.3 in 2023 with a different priority: stability and performance rather than new features. The original Iceshrimp codebase (Iceshrimp-JS) is winding down, receiving primarily security updates, while Iceshrimp.NET (a ground-up rewrite in C#) is where active development has shifted. It emphasizes strong Mastodon-API compatibility, so existing Mastodon clients work without modification.

Firefish (formerly Calckey) is the cautionary tale in this family. It launched as a heavily modified Misskey fork with an ambitious feature roadmap and attracted a significant user base. Then it ran into serious scaling problems on its flagship instances, governance turbulence as its original developer stepped back, and a series of developer departures that led directly to Catodon and Iceshrimp.

By the end of 2024, the lead developer announced Firefish was entering maintenance mode and would reach end of support at year's end. The original repositories were taken down and the main website began returning HTTP 410 Gone after February 2025, though community forks and mirrors remain. Admins migrated primarily to Sharkey, Iceshrimp, or vanilla Misskey. Catodon, started by former Firefish contributors, is targeting small-scale deployments and continues active development at a smaller scale.

For most practical purposes, if you're joining or evaluating a Misskey-family instance today, it's running Misskey, Sharkey, or Iceshrimp. Firefish is gone; Catodon and a handful of smaller forks exist but have limited footprint.

Pleroma and Akkoma: lightweight, with history

 Pleroma's core appeal is resource footprint. Mastodon requires a multi-process stack: Ruby, Sidekiq, PostgreSQL with meaningful RAM, and optionally Elasticsearch for search. Pleroma runs as a single Elixir application with a far smaller footprint than Mastodon. Typical deployments use around 200MB of RAM with PostgreSQL, and it can run on a Raspberry Pi. It supports the Mastodon client API, so Ivory, Elk, Phanpy, or any other Mastodon client works with a Pleroma account. Character limits default to 5,000. Quote posts are built in.

On the admin side, Pleroma's most distinctive tool is the Message Rewrite Facility (MRF): a rule engine that lets admins automatically transform, filter, or drop inbound and outbound activities before they reach timelines. It's more surgical than the blocklist-or-defederate binary that most ActivityPub servers offer, and it's one of the features that attracted technically inclined admins who want fine-grained control over what their instance sees.

Pleroma's configurability and minimal project-level stance on moderation policy also attracted a different kind of admin: the "free speech absolutist" variety, or simply instances with very permissive content norms. That reputation calcified. Pleroma the software didn't mandate it, but Pleroma instances became associated with it, and defederation from significant portions of the fediverse followed. That history hasn't fully separated from the software's name.

Akkoma forked from Pleroma in 2022, explicitly motivated by moving away from that ecosystem and toward more opinionated moderation defaults and faster development. The fork describes itself as "the cooler Pleroma": same Elixir stack, still lightweight, still Mastodon-API compatible, but with different defaults and a different community orientation. Domain blocks are enforced more aggressively by default. The bubble timeline lets clusters of instances form a curated shared feed together without opening the full federated firehose. Local-only posting keeps content on-instance when you don't want it to federate.

Akkoma has also borrowed selectively from the Misskey family: it supports custom emoji reactions with Misskey-compatible semantics, and renders Misskey Flavored Markdown (MFM), so expressive posts from Misskey users display correctly rather than rendering as raw markup. Automatic post translation via DeepL or LibreTranslate is built in. The net effect is a Pleroma-derived server with some Misskey-adjacent expressiveness without the resource requirements of the Misskey stack.

Many new small-to-medium instances in this space now choose Akkoma over Pleroma. Combined they account for around 650 servers and roughly 23,000 MAU: Pleroma still has more total instances, but the install trend has shifted.

Friendica: the multi-protocol bridge

 Friendica has been running since 2010. That's six years before Mastodon, and before the term "fediverse" was in common use. It's one of the oldest active federated social networks (GNU social, formerly StatusNet, dates to 2008) and the one most consistently oriented toward connecting networks rather than deepening any single one.

ActivityPub support landed in Friendica in 2019, but Friendica was already federating long before that, via Diaspora's protocol, its own DFRN (Distributed Friends and Relations Network) protocol, and OStatus. The core project goal has always been protocol breadth rather than protocol depth: Friendica wants to be the node that connects to networks other platforms can't see. Today that means ActivityPub (Mastodon, Misskey, Pleroma, Pixelfed), Diaspora*, email via IMAP/SMTP, RSS/Atom feeds, and plugins for external platforms including Bluesky and WordPress.

W3C social-web working groups cited Friendica specifically as the project already bridging OStatus and Diaspora before ActivityPub existed, earning a "federation world champion" label that's followed it ever since.

Where the other platforms in this post are opinionated ActivityPub apps, Friendica is closer to a multi-protocol social router. A Friendica user can follow a Mastodon account, a Diaspora pod contact, a Lemmy community (Friendica implements the Fediverse Enhancement Proposals or FEPs for ActivityPub group actors), and an RSS feed, all in a single timeline organized into contact circles. The UX reflects this: it's closer to a classic social network interface (rich BBCode text editor, circle-based contact management, events with RSVPs, granular per-post privacy controls) than to a microblog stream. It's better suited to power users who want tight control over a single curated timeline spanning multiple networks.

The 85 servers and 3,200 MAU that FediDB records for Friendica understate its actual reach, because Friendica users' interactions extend across Diaspora and other non-ActivityPub networks that aggregators don't count. At FOSDEM 2026, the Friendica team titled their talk "Hidden in plain sight since 2025." It's a fair self-assessment. Actively maintained, stable, and largely absent from the fediverse growth conversations that center on Mastodon and its closer competitors.

Hubzilla occupies similar territory but goes further. Created by Mike Macgirvin (the same developer behind DFRN, the protocol Friendica used before ActivityPub), Hubzilla speaks ActivityPub and its own Zot (now Nomad) protocol simultaneously. The distinguishing idea is nomadic identity: your Hubzilla account can be cloned across multiple hubs, and if one hub goes offline, your identity, social graph, and content survive intact on the others. It goes well beyond what ActivityPub's built-in account migration supports, coming closer to true portable identity than anything else in the fediverse. The tradeoff is complexity: Hubzilla is considerably harder to set up and administer than Friendica, and its ~1,450 MAU reflects a specialist audience. Worth knowing it exists; not a first choice for most deployments.

GoToSocial: the personal instance, made practical

GoToSocial exists for people who want a personal fediverse presence but find Mastodon too resource-heavy to self-host.

Written in Go, it uses roughly 250–350MB of RAM at rest. It can use SQLite as its database, eliminating the need for a separate PostgreSQL instance entirely. It has no web client of its own (though it serves basic profile and post pages): you connect through any Mastodon-API-compatible client (Ivory, Phanpy, Tusky, and others all work). The admin panel is minimal by design. It runs on a Raspberry Pi or a $5 VPS without strain.

GoToSocial is also safety-focused in ways that distinguish it from most other ActivityPub software. Interaction controls are unusually granular: you can specify per-account who can reply to your posts, who can follow you, and how your content appears in search. These controls operate at the individual account level, not just at the instance level.

GoToSocial is currently in beta, with a v1.0 release projected for sometime in 2026. FediDB counts 260+ known servers, but single-user instances running in private mode don't surface to aggregators, so both server count and MAU figures significantly understate the actual install base.

We'll cover GoToSocial in more depth in a future post, including self-hosted setup, configuration, and what to expect from running your own instance. For now: if you want a personal presence on the fediverse and don't need the full Mastodon feature set, GoToSocial is the option most worth looking at.

The Threadiverse

 Link aggregation, upvotes, and threaded community discussion rather than microblogging. Same ActivityPub protocol, completely different model. The communities building Reddit alternatives on this stack call it the Threadiverse.

Lemmy is dominant here: 423 servers and roughly 43,000 MAU, which by FediDB's current figures puts it ahead of both the Misskey family and Pleroma+Akkoma in monthly active users. PieFed is a growing alternative with 76 servers and around 4,800 MAU. Mbin rounds out the space at around 1,300 MAU; it's the active fork of kbin, which was an early Threadiverse entrant that has since become effectively historical. If you see kbin referenced anywhere, Mbin is its maintained successor.

Threadiverse platforms federate via ActivityPub, so Mastodon users can follow Lemmy communities and see posts in their home timeline. The interaction model (communities as the primary unit, link submission as the core action, upvotes rather than boosts) is different enough that the two social graphs rarely overlap in practice. The Threadiverse and the microblogging fediverse share a protocol. They don't share much else. Part 4 of this series covers Lemmy, PieFed, and Mbin, alongside NodeBB and Bookwyrm.

The technical choices are also social choices

The feature lists in this post look like engineering decisions. They're also decisions about who runs your server and who shows up.

Pleroma's MRF was designed for fine-grained admin control over inbound and outbound content. That capability attracted admins who wanted that control, and some who used it in ways that accumulated into a reputation. Akkoma forked specifically to shift the defaults and, with them, the communities that formed around it. Same wire protocol, different gradient, different outcome.

Misskey's expression-first design drew communities built around expressive posting culture. GoToSocial's minimal footprint selects for people who want a personal presence without becoming a server administrator. Friendica's protocol breadth attracts people whose social graph doesn't fit cleanly on any single network.

Not all of these platforms started with ActivityPub as their foundation. Misskey launched in 2014 and adopted it in 2018. Friendica has been federating since 2010 (via Diaspora*, its own DFRN protocol, and OStatus) and added ActivityPub in 2019 when the network effects made it worth implementing. These weren't platforms built around a spec. They were platforms with their own visions of what federated social software should look like, which converged on ActivityPub as a pragmatic interoperability layer.

ActivityPub doesn't have opinions about any of this. The spec moves data between servers. What each implementation built on top of that, and what they chose not to build, gave the fediverse its actual shape and it continues to evolve.

Sources and further reading

Fediverse statistics

• FediDB Software Stats — per-platform MAU, server counts, and account totals; June 2026 data used in this post
• Fediverse Observer — alternative aggregator; useful for instance-level geographic and uptime data

Misskey and forks

• Misskey — Join the Fediverse Wiki — overview of Misskey's design philosophy and feature set
• Misskey — The Fediverse Wiki — community-maintained reference
• Sharkey — the most actively maintained Misskey soft fork; primary migration target from Firefish
• Iceshrimp — the Iceshrimp.NET rewrite project; JS branch winding down
• Catodon — fork by former Firefish contributors; targets small-scale deployments

Pleroma and Akkoma

• Akkoma — project home; self-describes as "the cooler Pleroma"
• Akkoma documentation — covers MFM support, bubble timeline, domain block defaults, migration from Pleroma
• Akkoma — Join the Fediverse Wiki — feature comparison with Pleroma mainline
• Pleroma — NLnet project page — covers MRF (Message Rewrite Facility) and ActivityPub implementation
• Mastodon vs Pleroma — side-by-side on resource requirements and feature differences

Friendica and Hubzilla

• Friendica — project home
• Friendica ActivityPub announcement (2019.01) — covers the AP implementation scope and initial federation testing against Mastodon, Pleroma, PeerTube, Pixelfed
• Friendica FEDERATION.md — current protocol support list: ActivityPub, Diaspora*, DFRN, OStatus, FEPs for group federation and NodeInfo
• Friendica — The Fediverse Wiki — feature overview and protocol support
• Hubzilla — project home; covers Zot protocol and nomadic identity

GoToSocial

• GoToSocial Documentation — official docs; covers setup, configuration, and feature set
• GoToSocial — The Fediverse Wiki — community reference
• GoToSocial — ElfHosted managed hosting — managed hosting option for those who want GTS without self-hosting

Link aggregators

• Lemmy — project home and instance directory
• PieFed — project home

What's Next: Part 2 of this series looks at the visual fediverse (Pixelfed, Loops, and PeerTube) and what it means to own your visual presence on the open web.

Subscribe to get notified about Part 2!