Andrew Mercer
on this page

What it is

Threads is Meta's Twitter/X-style app, launched in mid-2023 — and, unlike every other app covered in this section, it's a fully centralized product that chose to layer optional, partial [[activitypub|ActivityPub]] federation on top rather than being built on an open protocol from the ground up. That makes it a genuinely different case study from Mastodon or Bluesky: the question isn't "how does this decentralized network work," it's "what happens when the fediverse's single largest population of accounts lives inside a server nobody else controls."

By raw numbers, Threads dwarfs the rest of the ActivityPub-speaking fediverse combined — reported past 400 million monthly active users, against roughly 10 million registered Mastodon accounts and well under a million Mastodon monthly actives. That scale imbalance is the central tension discussed below.

How the federation feature actually works

Federation on Threads is opt-in, account-by-account, not a default. As rolled out in stages from late 2024 through mid-2025:

  • A user turns on "Fediverse sharing" in account settings; the account must be public and the user must meet a minimum age requirement. The feature was geographically limited at launch and wasn't available in some regions, including, at various points, parts of the EU.
  • Once enabled, a Threads post exists as an ActivityPub object other fediverse servers can see, follow, and interact with — but discovery initially depended on activity: a Mastodon user typically had to already like, reply to, or follow a federated Threads account before it became easy to find.
  • Later updates added direct lookup by full fediverse address (@[email protected] search) and a dedicated, reverse-chronological feed of posts from federated accounts you follow — separate from the main Threads algorithmic feed, not merged into it.
  • Meta has named Mastodon, BookWyrm, and WriteFreely among the connected services it explicitly tests against.

What works, and what doesn't

Generally supported: following a federated account across the Threads/fediverse boundary, viewing federated posts, replying and liking in a way that's visible on both sides for accounts that have opted in on both ends.

Partial, inconsistent, or unsupported: notifications across the boundary can be delayed or simply not arrive; blocking and deletion don't reliably propagate to every server that received the original post, so content can persist elsewhere after being taken down on Threads; moderation standards differ entirely between Threads (Meta's centralized trust-and-safety policy) and whichever independent instance a given interaction touches; not every Mastodon account is reachable from Threads, since privacy settings, instance-level suspensions, and defederation choices on the Mastodon side can all block the connection regardless of what Threads itself supports.

Explicitly out of scope: this integration is ActivityPub-only. Threads has no native interop with [[at-protocol|AT Protocol]]/Bluesky — the two largest "post-Twitter" platforms remain mutually unreachable without a third-party bridge like Bridgy Fed, same as discussed in the Bluesky guide.

Why this is controversial inside the fediverse

The debate isn't really about the technical implementation — it's about what a single large corporate account means for a network whose entire premise is that no one company should be able to dominate it:

  • The case for welcoming it: more federation is more federation. A Mastodon user can reach Threads accounts they otherwise couldn't, and some view any ActivityPub adoption by a mainstream player as validating the protocol and expanding its real-world relevance.
  • The case for wariness (sometimes summarized as "embrace, extend, extinguish" concerns borrowed from historical open-protocol fights): Threads' federation is opt-in and Meta-controlled at every layer — which accounts can federate, which servers Threads will accept activities from, and whether any given feature ships at all remain entirely Meta's call, with no obligation to keep parity with the open spec. A number of existing Mastodon instances have pre-emptively defederated from Threads specifically to avoid being dependent on infrastructure they don't control.
  • The scale asymmetry itself is the real issue many raise: when one company's opt-in, partially-compatible product has more monthly active users than the rest of the fediverse combined, "the fediverse" as a decentralized ecosystem and "accounts that happen to speak some ActivityPub" start to mean different things — and conversations about ActivityPub's future increasingly have to account for Meta's incentives whether or not any given fediverse user ever interacts with Threads directly.

Strengths and weaknesses

Strengths: brings ActivityPub-based interaction to Meta's existing, very large user base at no signup cost to them; concrete evidence that a major platform will adopt an open federation protocol rather than building a fully closed walled garden; funds continued engineering investment in ActivityPub tooling that benefits the wider ecosystem indirectly.

Weaknesses: federation is opt-in, partial, and unilaterally controlled by Meta; no cross-protocol reach to AT Protocol; moderation, notification delivery, and deletion propagation are all weaker across the Threads/fediverse boundary than within either side alone; raises the structural concern of one company's product dwarfing the rest of an ostensibly decentralized network in active-user terms.

Further reading