Mastodon instance defederation is the process where one server blocks another server from interacting with it. When an admin defederates a remote instance, users on that blocked server can no longer follow local accounts, boost local posts, or send direct messages to local users. The blocked server also disappears from the local federated timeline. This article explains the technical and social reasons why admins decide to defederate, how they evaluate instances, and what tools they use to maintain block lists.
Key Takeaways: Mastodon Instance Defederation and Admin Block Lists
- Admin > Moderation > Instances > Block: The main interface to add a remote instance to the server block list.
- Federation reports and content violations: The most common trigger for defederation reviews by admins.
- Silence vs Suspend: Silence hides content from local timelines; Suspend fully blocks all federation with the remote instance.
Why Mastodon Admins Defederate Instances
Defederation is not a casual decision. Most admins follow a documented policy or community guidelines before adding an instance to a block list. The primary reasons fall into three categories: policy violations, technical abuse, and legal or safety risks.
Policy violations include instances that host hate speech, harassment, illegal content, or spam. Many Mastodon servers publish a code of conduct that explicitly bans these categories. When a remote instance tolerates or encourages such behavior, local admins may defederate to protect their own users from exposure.
Technical abuse covers instances that spam the federated timeline with automated posts, attempt denial-of-service attacks, or exploit Mastodon software bugs. Admins monitor server logs and resource usage to detect these patterns. A sudden surge in federation traffic from a single instance often triggers a review.
Legal or safety risks arise when an instance operates in a jurisdiction with laws that conflict with the local server’s policies. Examples include instances that host content illegal in the admin’s country or that fail to comply with data protection regulations like the GDPR. Admins may also defederate instances that repeatedly send death threats or doxxing content to local users.
How Admins Evaluate Instances for Defederation
Admins use a combination of manual review, community reports, and shared block lists to decide whether to defederate an instance. The evaluation process typically follows these steps.
- Review reports from local users
Local users can report individual posts or accounts from remote instances. Each report includes the content that violated the local server’s rules. Admins check the report details and the remote instance’s public timeline to assess the severity. - Check the remote instance’s rules and moderation
Admins visit the remote instance’s about page to read its server rules. They look for evidence that the instance actively moderates content. An instance with no visible rules or no active moderation team is more likely to be defederated. - Consult shared block lists from trusted communities
Many Mastodon admin groups maintain shared block lists. Examples include the FediBlock list and instance-specific block lists maintained by large servers like mastodon.social. Admins import these lists to preemptively block known problematic instances. - Observe federation behavior over time
Admins monitor how the remote instance interacts with their server. They check whether the instance sends spam, attempts to follow large numbers of local accounts in a short time, or posts content that triggers automated moderation filters.
After evaluation, the admin chooses one of three actions: no action, silence, or suspend. Silence hides the remote instance’s content from local public timelines and trending views but still allows local users to follow accounts on that instance if they search manually. Suspend completely blocks all federation with the remote instance.
Tools Admins Use to Manage Block Lists
Mastodon provides built-in moderation tools for defederation. Admins access these through the server administration panel. The most common tools are described below.
Admin > Moderation > Instances
This page lists all remote instances that have federated with the local server. Each entry shows the instance domain, the number of known accounts, and the current moderation action (none, silence, or suspend). Admins can click on any instance to view details and change the action.
Domain block form
The domain block form allows admins to add a new instance to the block list. They enter the instance domain, select the action (silence or suspend), and optionally add a private note explaining the reason. The note is visible only to local admins.
Import and export of block lists
Admins can export their current block list as a CSV file. They can also import a CSV file containing domains and actions. This feature enables sharing block lists between servers. Many admins regularly import updated lists from community-maintained sources.
Automated moderation tools
Some Mastodon servers run third-party scripts that automatically flag or block instances based on keywords, account age, or federation patterns. These scripts are not part of the core Mastodon software but are popular among large instances. Admins must configure these tools carefully to avoid false positives.
Common Misconceptions About Defederation
Defederation is permanent and irreversible
Defederation is reversible. An admin can remove a block from an instance at any time. However, when a suspend is lifted, the local server must re-federate with the remote instance. This process can take hours or days depending on server load. Silences are easier to reverse because the federation connection remains active.
Defederation blocks all content from an instance
A suspend does block all federation. But a silence only hides content from public timelines. Local users can still follow accounts on a silenced instance and see their posts in their home feed. Direct messages between local users and accounts on a silenced instance also remain functional.
Shared block lists are always accurate
Shared block lists can contain outdated or incorrect entries. An instance may have changed its moderation team or policies after being added to a list. Admins should verify each entry before importing. Relying solely on shared lists without manual review can block legitimate instances.
| Item | Silence | Suspend |
|---|---|---|
| Effect on public timelines | Hides content from local public timelines and trending | Removes all content from local server entirely |
| Local users can follow remote accounts | Yes, by searching manually | No |
| Direct messages still work | Yes | No |
| Reversibility | Instant | Requires re-federation |
Admins choose silence when they want to limit visibility but allow voluntary interaction. They choose suspend when they want to completely sever ties with an instance that poses a serious risk or consistently violates policies.
After implementing a defederation decision, admins should communicate the change to their user base. Many servers post a notice in their local feed or publish a moderation log. Users who follow accounts on the blocked instance will lose access to those accounts. Admins should provide guidance on how to find alternative accounts on other instances.
For users who want to understand their own server’s block list, most Mastodon instances publish a list of defederated domains on their about page. Look for a link labeled “Moderation” or “Server rules” on the instance’s homepage. If the list is not visible, users can ask the admin directly by sending a message to the moderation account.