Mastodon Relay Pub-Sub Model: How It Differs From Direct Federation

Mastodon instances can exchange posts using two distinct methods: direct federation and relay-based pub-sub. Direct federation pushes content from one instance to another only when someone follows a user on the remote server. A relay, by contrast, acts as a central hub that broadcasts posts to all subscribed instances, regardless of who follows whom. This article explains the technical differences between the two models, their use cases, and the trade-offs involved. You will learn how relays affect server load, content reach, and moderation control.

How Mastodon Federation Works at a Technical Level

Mastodon uses the ActivityPub protocol to exchange activities between instances. An activity can be a post, a boost, a follow, or a delete. Every instance runs its own ActivityPub server that sends and receives these activities over HTTPS. The protocol defines two delivery patterns: push-based direct delivery and pull-based relay delivery through a shared inbox.

Direct Federation: One-to-One Delivery

In direct federation, Instance A sends a new post to Instance B only if at least one user on Instance B follows the author on Instance A. The post is delivered to the shared inbox of Instance B, which then distributes it to the home timelines of the followers. This model is efficient because it transfers only content that has active local demand. Each instance maintains a list of remote users that its users follow and caches their recent posts. The downside is that an instance cannot discover content from a remote user unless someone on the instance already follows that user.

Relay Pub-Sub Model: Many-to-Many Broadcast

A relay is a special ActivityPub actor that sits between instances. An instance can subscribe to a relay, becoming a subscriber, and also publish its public posts to the relay. When a publisher instance sends a new post to the relay, the relay forwards that post to every subscribed instance. This happens regardless of whether any user on the subscriber instance follows the original author. The relay acts as a force multiplier: one post sent to the relay reaches dozens or hundreds of instances in seconds.

The relay uses the shared inbox endpoint of each subscriber instance, the same endpoint used for direct delivery. The difference is that the relay sends every post from every publisher to every subscriber, whereas direct federation sends only posts from users who are followed on the target instance.

Differences in Reach, Performance, and Control

The choice between direct federation and relay pub-sub affects three key areas: how far content spreads, how much server load each instance carries, and how much control administrators have over incoming content.

Content Reach

Direct federation limits reach to the follower graph. A post from a small account on a small instance may never leave that instance if no one on other instances follows the account. Relays solve this by broadcasting all public posts to all subscribers. A post from a new user on a relay-connected instance can appear on dozens of remote timelines immediately, even if the user has zero followers elsewhere. This makes relays useful for topic-specific communities, such as a relay for a programming language or a hobby, where users want to see all posts on that topic from many instances.

Server Load and Bandwidth

Direct federation scales linearly with the number of remote users that local users follow. If an instance has 100 users each following 200 remote accounts, the instance receives posts from up to 20,000 remote accounts. A relay, however, sends every post from every publisher. If the relay has 50 publishers and each publishes 100 posts per day, the relay sends 5,000 posts per day to every subscriber. For a subscriber with 10 relays, that becomes 50,000 posts per day, many of which may be irrelevant. The relay itself also bears the cost of processing and forwarding all those posts.

Moderation Granularity

With direct federation, an administrator can block or limit a specific remote user who posts problematic content. The block applies only to that user, not to the entire remote instance. With a relay, the administrator must either accept all content from the relay or unsubscribe from it entirely. There is no way to block individual publishers from a relay unless the relay itself provides a moderation interface, which few do. Some relays allow administrators to set a domain block list, but that blocks the entire publishing instance, not individual accounts.

When to Use a Relay vs Direct Federation

Small instances with few users often benefit from relays because they lack the follower base to discover content through direct federation alone. A relay brings in a steady stream of public posts, filling local timelines with content from the wider fediverse. Large instances with thousands of users usually do not need relays because their users already follow enough remote accounts to generate a rich feed. Adding a relay to a large instance can overwhelm the server with duplicate or irrelevant posts.

Topic-specific relays work well for niche communities. For example, a relay for photographers can aggregate posts tagged with photography hashtags from many instances. Users on subscriber instances see all those posts without having to follow each photographer individually. The relay operator must maintain the relay server and moderate it if needed.

Common Misconceptions and Limitations

Relays Increase Server Load More Than Direct Federation

This is generally true but depends on the size of the instance. For an instance with fewer than 50 active users, a relay may add less load than manually following thousands of remote accounts. For a large instance, the relay load can exceed the load from direct federation by a factor of ten. Administrators should monitor CPU and memory usage after adding a relay and remove it if performance degrades.

Relays Bypass Follower Privacy Settings

Relays only forward public posts. Unlisted, followers-only, and direct messages are never sent to a relay. The Mastodon server checks the post visibility before delivering it to the relay’s shared inbox. Private posts remain private regardless of relay subscriptions.

Direct Federation Can Be Slower for New Content Discovery

Without a relay, an instance can only discover content from users that its members already follow. Trending or viral content from outside that graph may never appear. Relays solve this by bringing in content from many instances, but the trade-off is lower relevance and higher noise.

Direct Federation vs Relay Pub-Sub: Feature Comparison

Item	Direct Federation	Relay Pub-Sub
Delivery trigger	Local user follows a remote user	Publisher sends post to relay
Content scope	Only posts from followed users	All public posts from all publishers
Server load	Proportional to follower count	Proportional to number of publishers and relays
Moderation control	Block individual remote users	Block entire relay or domain
Content discovery	Limited to follower graph	Broad, includes new accounts
Privacy	Public and private posts respected	Only public posts forwarded
Setup complexity	Automatic, no configuration needed	Requires relay URL and subscription

Direct federation is the default mode for all Mastodon instances. Relays are an optional add-on that an administrator can enable from the instance’s administration panel under Administration > Relays. The relay URL must be provided by the relay operator, and the instance must subscribe to it. Once subscribed, the instance both sends its public posts to the relay and receives posts from other subscribers.

Relays have no effect on private or unlisted posts. They also do not affect boosts or replies unless those activities are public. The relay simply forwards whatever public activities it receives from its publishers.

If you run a small instance and want to see more diverse content without manually following hundreds of accounts, subscribing to one or two topic-specific relays can help. Monitor your server resources after adding a relay. If the server becomes slow, remove the relay and rely on direct federation instead. For large instances, direct federation is almost always sufficient and safer for performance.