Does Threads Work With Mastodon? Fediverse Basics

Yes, in part. Threads can connect to Mastodon through the fediverse, but only for accounts that choose to turn it on, and only where Meta has made it available. Once an eligible Threads account shares to the fediverse, people on Mastodon and other compatible servers can find it, follow it and reply to its posts without a Threads account of their own.

This guide explains what that means in plain terms: what the fediverse is, how a single post travels between servers, what Meta has said about Threads and where the limits are. It then covers what federation changes for moderation, money and exit, so you can decide whether a network of your own should connect. If you are planning one, a white-label Threads clone can be built with federation as an option, and we come back to that near the end.

What the fediverse is

The fediverse is a group of social servers that use shared rules to exchange posts. Meta's own newsroom describes it as a global, open network of interconnected but still independent social media servers, each with its own users, content and rules. Its comparison is email: someone on one provider can write to someone on another, because the providers share a protocol.

Mastodon describes itself in similar terms. Each Mastodon server is an independent entity that can interoperate with others to form one global social network. You can join an existing server or host your own. Mastodon says it is built on open web protocols and can speak with any other platform that implements ActivityPub, which gives its members access to what it calls the fediverse.

Two points follow from this. The fediverse is not a company, so there is no central switch to turn it on. And Threads is, in Meta's words, one participating server among many, not the owner of the network. The comparison with a regional telephone company helps: joining a network of networks does not give you control of the network.

What ActivityPub does

ActivityPub is the protocol behind most of the fediverse. The W3C published it as a Recommendation on January 23, 2018. It describes two connected interfaces. One is a client-to-server API, used by an app talking to its own server to create, update and delete content. The other is a server-to-server API, used by servers to deliver content and notifications to each other.

The vocabulary in four terms

• Actor. A user on the network, which can be a person, an organization, a bot or an automated process. Each actor has a unique identifier that works like an address.
• Inbox. Where an actor receives messages from others. Reading your inbox gives you your feed.
• Outbox. Where an actor sends messages out. Posting to your outbox publishes content.
• Activity. A described action, such as Create (make something new) or Follow (subscribe to an actor).

One post, step by step

Say Mira has an account on Server A, and Jonas has an account on Server B. Jonas follows Mira. The example names are invented, and the steps follow the protocol's own model.

1. Jonas asks to follow Mira. His server sends a Follow activity to Mira's inbox on Server A. When Mira's side accepts, the protocol says the server should add Mira to Jonas's list of accounts he follows, so the subscription is recorded.
2. Mira writes a post. Her app sends it to her server's outbox. The protocol says that when a plain object is posted, the server wraps it in a Create activity so that it becomes an action other servers can understand.
3. Server A looks at who the post is addressed to, which includes Mira's followers, and works out the list of recipients. The protocol requires removing duplicates so no one gets the same item twice.
4. For each recipient on another server, Server A delivers the activity by posting it to that actor's inbox. Jonas's inbox is on Server B, so Server B receives the post.
5. Jonas opens his app. When his app reads his inbox, the post is in his feed, as if it had come from his own server.
6. Jonas replies. The same steps run in reverse: his server wraps his reply in a Create activity, addresses it to Mira, and delivers it to her inbox on Server A.

Each server stores its own copy of what it receives. That is why the fediverse feels fast and local, and also why a deleted post does not always vanish everywhere at once. Deletion is also an activity that must be delivered, and a server that refuses it, or is offline, may keep an old copy.

What Threads has done with federation

This section states only what Meta's own pages say, and it is dated. The details can change, so check Meta's current Help Center pages before relying on them.

Putting those together, the state of play as of October 2026, based on the latest Meta page opened for this guide, is as follows.

• It is opt-in. A person must choose to share. Posts do not leave Threads by default.
• It is for adults with public profiles. Meta states both conditions.
• Others can interact without a Threads account. Meta says users on other servers can search for, follow and interact with the profile.
• Threads users can read back. The June 2025 feature is a feed of posts from federated accounts you follow, in reverse chronological order, plus search for fediverse profiles.
• It was not available in the European Region. Meta's June 2025 post says so. Regional availability may have changed since then.
• Meta cautions about privacy. Its fediverse explainer says sharing to the fediverse affects your privacy and control over your information.

Meta also said in that June 2025 post that Threads had interacted with over 75 percent of all fediverse servers in the year since sharing launched. That figure is Meta's own and describes servers it has exchanged activity with, not the number of people or posts.

The Mastodon side: the server decides

Federation is a two-way agreement. Meta can send posts out, but each Mastodon server chooses what to accept. Mastodon's own July 2023 post on Threads says individual server operators keep the power to allow or block Threads communication, and that members unhappy with their server's choice can move to another and keep their followers. It adds that Threads cannot enforce its moderation rules on other platforms, because its decisions affect only its own platform, and that Threads would not be able to collect private information from a Mastodon server.

The moderation documentation spells out the tools an administrator has. Limiting a whole remote server is equivalent to limiting all past and future accounts on it, and turns incoming follows into follow requests. Suspending a remote server is equivalent to suspending all of its accounts, with no content stored locally except usernames, and it removes follow relationships between the two sides. Domain blocks come in several severity levels, can reject media files from a blocked server, and can be imported as shared block lists from other administrators.

The practical result: you cannot assume that a Mastodon user can see a Threads account just because both sides are in the fediverse. They can if the user's server allows it and the Threads account has shared. If either condition fails, nothing arrives.

What federation changes for moderation

In a closed network, one team decides what stays. In a federated one, many teams decide, and none can overrule the rest. That produces four changes.

1. Moderation becomes local. Your server's rules apply to your members and to what your server chooses to display. A post that is fine on another server may be hidden on yours.
2. Remote abuse is handled by blocking, not by deletion. You cannot delete a post on another server. You can stop your members from seeing it.
3. Reports cross servers. A member on your server may report a remote account, and you can act on your side only.
4. Volume rises. Receiving posts from many servers means more content to screen than your own members create.

For a small operator, the question is capacity. Each remote server is a possible source of reports and a possible source of abusive content, and someone has to read the queue. For the models behind this, see Mastodon vs Bluesky vs a private network, and for a broader look at moderation approaches, our guide to content moderation models.

What a closed network gives up, and what it keeps

A closed network keeps control over identity, advertising and payments. It gives up reach beyond its own members and a built-in exit for them. Neither choice is wrong. A trade association, a paid community or an adult-verified space may want the wall. A public conversation app that wants to be found may not.

The same trade-off applies in other formats. A short-video app such as a TikTok clone usually keeps its graph closed because the feed algorithm is the product. A paid-access network such as an OnlyFans clone keeps posts private by design, so federating would work against its model. Serialized video, as in a ReelShort clone, has no social graph to share. Text is the format where federation makes the most sense, because posts are small, public and cheap to copy.

Edits, deletes and what leaves a trail

Because every server keeps its own copy, three everyday actions need a second look before you promise members anything.

• Deleting a post. The deletion is itself an activity that has to be delivered. A server that is offline, or one that ignores the request, may keep the old copy. Tell members that deletion is a request to other servers, not a guarantee.
• Blocking someone. A block on your server stops your members from seeing that account. It does not stop the account from existing elsewhere.
• Leaving. A member who moves servers keeps their followers on compatible servers, as Mastodon notes, but their old posts may stay behind on the old server.

These points matter for privacy notices. A closed network can say it deletes data from its own database. A federated one has to say what it can and cannot do about copies held by others.

Federation readiness table for an operator

Common misunderstandings

• "Federated means decentralized in every way." It means servers exchange posts. A very large server can still hold most of the audience.
• "Joining the fediverse means everyone can see my account." Only servers that accept yours can, and only if sharing is on.
• "Federation gives me the follower list." Not necessarily. What one server shows about followers on other servers depends on how each is built.
• "Open means federated." A network can be open to export and developers without federating.
• "Federation ends moderation work." It spreads the work across many operators and adds new tasks for each.

What a reader will notice

From a member's chair, federation shows up in small ways. Handles look like email addresses, with the name and the server together. A search can return people on many servers. A reply from a stranger on another server may arrive with no sign that they were never on your app. A server that your home server has blocked simply goes quiet.

That is why a clear help page matters more on a federated network than on a closed one. Members need to know why an account cannot be found, what an administrator can limit, and how to move to a different server if theirs makes a choice they dislike. A closed network answers those questions with one policy. A federated one answers them with a short guide to how the pieces fit.

Should your network federate?

Use these questions to decide.

1. Is your content meant to be public? If most posts are public conversation, federation fits. If most are paid or private, it does not.
2. Do you need reach you do not have? Federation gives a small server an audience on day one. A closed network has to earn one.
3. Can you moderate remote content? Count the staff time before you connect.
4. Who will pay for hosting? Receiving posts from many servers uses storage and bandwidth.
5. What do you promise advertisers or members? A brand-safe, closed environment is a product. So is an open one. Do not promise both.

If the answer is yes, there are two routes. You can host a Mastodon server, which gives you federation and a community without building software. Or you can run your own product, such as a ready-made Threads clone script, and add ActivityPub support. For the second route, we set up federation for your build, and the exact scope is confirmed with us at kickoff through the contact page. Our baseline product already covers the member-facing pieces in the Threads clone features list: four feeds, consent-gated messaging, threaded posts and an operator console.

Questions to ask before connecting

• How will you handle a server that sends abuse?
• What happens to a member's posts if you disconnect?
• Can a member who leaves take their followers with them?
• How do deletions propagate, and what will you tell members about copies?
• Does your privacy notice say plainly what leaves your servers?

Glossary

• Fediverse: the set of servers that exchange posts using shared protocols.
• ActivityPub: the W3C protocol that defines actors, inboxes, outboxes and activities.
• Instance or server: one independent installation, with its own members and rules.
• Domain block: a server-level decision to limit or cut off another server.
• Opt-in sharing: a setting that a member must turn on before posts leave the home server.

What to decide next

If you are a reader, check whether your Threads account has sharing on and whether your Mastodon server allows Threads. If you are an operator, decide first whether your content is public, then whether you can afford the moderation, and only then choose a route. Weigh the money side too: how Threads makes money explains why a company with a large closed graph can afford to open a small door, and the Threads clone business model page shows how an owned network earns instead. For the wider field of alternatives, see apps like Threads compared.

Everything attributed to Meta, Mastodon and the W3C above comes from their own pages and is accurate as of October 2026. Features and availability change, so check each source before you act.