Stop Posting to Platforms — Turn Your Website into a Fediverse Node

Introduction

Social media platforms increasingly feel like unstable ground. What once started as an open ecosystem of blogs, forums and independently operated websites has largely been replaced by centralized platforms that control distribution, visibility and ultimately the relationship between publishers and their audiences. Algorithms decide who gets seen, platform policies define what remains online and entire communities can disappear behind paywalls, moderation changes or corporate pivots almost overnight.

The ongoing fragmentation of social media is a direct consequence of this growing dissatisfaction. X continues to alienate parts of its user base, Meta launched Threads as its answer to decentralized social networking, Bluesky pushes its own federated protocol and Nostr experiments with a radically different architecture altogether. The pressure on traditional platforms is clearly increasing. Users, publishers and creators are actively looking for alternatives that offer more control, healthier communities and less dependence on single corporations.

Yet many of these alternatives still reproduce familiar platform dynamics. Some merely decentralize infrastructure while keeping the platform-centric model intact. Others introduce new protocols but remain heavily tied to proprietary ecosystems, venture capital or centralized discovery mechanisms. In many discussions, the Fediverse itself is also reduced to little more than “the Mastodon alternative to Twitter” — a framing that dramatically undersells its actual potential.

Because the real innovation of the Fediverse is not Mastodon. It is ActivityPub.

ActivityPub turns social networking from a platform feature into an open web standard. And once social interaction becomes a protocol instead of a product, ordinary websites can participate directly. Blogs no longer need to rely exclusively on external platforms for distribution and discussion. They can become part of the social web themselves.

This is where WordPress and the ActivityPub plugin become surprisingly powerful. With relatively little effort, an ordinary (self-)hosted website can transform into a fully federated Fediverse node. Users can follow posts directly from Mastodon or other ActivityPub-compatible platforms, replies can flow back into WordPress comments and the website itself becomes an active participant in decentralized social networking.

In many ways, this feels less like inventing something entirely new and more like returning the web to what it originally was supposed to be: open, distributed and owned by the people publishing on it.

This article explores both the idea and the practical implementation behind this approach. It takes a closer look at the limitations of platform-centric social media, explains the architecture and philosophy of the Fediverse and shows how the WordPress ActivityPub plugin can transform a traditional blog into a federated social presence. Along the way, we will cover federation models, moderation challenges, reverse proxy considerations, privacy implications and practical configuration recommendations for running a production-ready setup.

The Platform Trap

For years, the dominant promise of social media platforms was simple: publish content, reach an audience and participate in global conversations without needing to operate your own infrastructure. In many ways, that promise worked. Platforms like Twitter, Facebook, Reddit or LinkedIn drastically lowered the barrier to publication and allowed creators, journalists and independent websites to reach audiences at a scale that previously required significant technical and financial resources.

But this convenience came at a cost.

Modern social media increasingly operates on a model where creators produce the value while platforms control the visibility, monetization and audience relationships built around it. Followers are not truly portable, timelines are shaped by opaque recommendation algorithms and distribution can change dramatically overnight without warning or recourse. Publishers effectively build their communities on infrastructure they neither control nor meaningfully influence.

This dependency has become increasingly visible over the past years. Platform owners regularly alter APIs, restrict third-party access, introduce aggressive monetization strategies or deprioritize external links in favor of keeping engagement inside their own ecosystems. In practice, this often punishes exactly the kind of independent publishing the web originally enabled.

The result is a strange paradox: many creators technically own their websites, domains and content archives, yet their actual audience reach depends almost entirely on external platforms. Websites have increasingly become passive destinations while social networks act as the gatekeepers deciding whether anybody sees new content in the first place.

And the rise of large language models threatens to intensify this imbalance even further.

Traditional search engines at least still directed users towards original sources. AI-driven discovery increasingly removes even that remaining connection. Instead of visiting websites directly, users now consume summarized, reinterpreted or fully synthesized content inside AI interfaces controlled by a small number of large technology companies. The original publication often becomes invisible background material feeding proprietary systems.

One Fediverse user summarized this development rather bluntly after Google’s recent AI announcements: the web itself risks being reduced to “unpaid raw material for synthetic text extruders.” The concern may sound dramatic, but the underlying criticism is difficult to dismiss. Once information becomes detached from its original context, links, authorship and publication environments lose relevance. The website no longer matters as a destination or social space — only as training data and extraction source.

This creates a new abstraction layer above the open web itself. Not unlike previous platform shifts, control increasingly moves away from publishers and towards intermediaries deciding how information is surfaced, summarized and consumed. The danger is not merely technical centralization but cultural centralization: participation on the web risks being reduced to passive consumption inside ecosystems operated by a handful of corporations.

At the same time, social media itself has become increasingly unstable and fragmented. Elon Musk’s takeover of Twitter — now X — accelerated existing concerns around moderation, governance, platform reliability and the growing influence of individual billionaires over global communication infrastructure. Meta aggressively pushes Threads into the market, Bluesky positions itself as a decentralized alternative and protocols like Nostr experiment with entirely different models for identity and communication.

Yet many of these alternatives still preserve important forms of centralization.

Bluesky, for example, decentralizes parts of the protocol stack through the AT Protocol, but discovery, infrastructure and network effects still remain heavily tied to the company operating the ecosystem. Threads supports selected parts of ActivityPub, while remaining deeply integrated into Meta’s existing platform architecture. Even projects advocating decentralization often continue to revolve around centrally managed applications, venture-backed infrastructure or company-controlled discovery systems.

The industry clearly recognizes that centralized social networking has entered a period of instability. Yet most proposed alternatives still preserve the same underlying assumption that social interaction primarily happens on platforms.

This is precisely where the Fediverse introduces a fundamentally different idea.

Instead of building yet another platform, ActivityPub turns social networking itself into a protocol layer of the open web. Communication no longer has to be tied to a single service. Any compatible application — including ordinary self-hosted websites — can participate directly.

That distinction matters more than it initially appears.

Because once websites themselves become social actors again, publishers regain something platforms gradually took away, direct ownership over identity, audience and distribution.

The Fediverse Is More Than Mastodon

When people first encounter the Fediverse, they often associate it almost exclusively with Mastodon. This is understandable: Mastodon became the most visible alternative to Twitter during the ongoing turbulence surrounding X and introduced many users to the idea of decentralized social networking for the first time.

But reducing the Fediverse to Mastodon fundamentally misunderstands what makes the ecosystem interesting in the first place.

Mastodon is merely one application within a much larger federated network built around open communication standards — most importantly ActivityPub. The protocol itself is the actual innovation. It allows entirely different platforms, applications and publishing systems to communicate with each other without requiring centralized ownership or control.

In practice, this means the Fediverse is not a single website or service but an ecosystem of independently operated servers and applications that can interact across software boundaries.

A Mastodon user can follow a PeerTube channel. A Pixelfed user can comment on a WordPress article. A WriteFreely blog can interact with users on Friendica or Misskey. Despite vastly different interfaces and use cases, all of these systems can participate in the same social graph through a shared protocol layer.

This interoperability sharply contrasts with traditional platform ecosystems. Social media companies historically treat interoperability as a threat rather than a feature. Communication remains locked inside proprietary silos where users, audiences and content are tightly coupled to specific platforms. Even platforms that appear similar often cannot communicate with each other directly.

The Fediverse inverts this model.

Instead of forcing everybody into one centralized application, it treats social interaction as a distributed network of independently operated nodes. Different communities can establish their own moderation policies, hosting models and technical architectures while still remaining connected through federation.

This distinction also explains why ActivityPub matters far beyond microblogging.

The protocol is flexible enough to support entirely different forms of communication:

• short-form social posting
• long-form blogging
• image sharing
• video platforms
• forums and link aggregation
• collaborative publishing
• even self-hosted personal websites

In many ways, ActivityPub does for social interaction what email once did for messaging. It creates a common protocol that allows independently operated systems to exchange information without requiring a single controlling provider.

This decentralized structure naturally introduces trade-offs. Federation can be messy, moderation becomes more distributed and user experiences are often less polished compared to highly centralized commercial platforms. Discovery also works differently in an ecosystem without a single global recommendation algorithm optimizing engagement.

But these limitations are closely tied to the Fediverse’s core strength: No single company owns the network itself.

No corporation can unilaterally redefine visibility rules for the entire ecosystem. No platform owner can suddenly lock communities behind proprietary APIs or force users into algorithmically optimized engagement loops. Individual servers may disappear, communities may migrate and software projects may evolve independently — yet the larger network can continue to exist because the protocol itself remains open.

And this is exactly where websites and blogs become relevant again.

Once ActivityPub is understood as a general-purpose social protocol rather than merely “the Mastodon protocol,” a different possibility emerges: websites themselves can participate directly in the social web without depending on external platforms as intermediaries.

A self-hosted WordPress installation can effectively become its own federated social node — fully owned, fully controlled and directly connected to the broader Fediverse.

Your Website Can Become a Social Network Node

One of the most overlooked aspects of the Fediverse is that participation does not require joining yet another social media platform.

You do not necessarily need a Mastodon server! You do not need to migrate your audience into a new ecosystem! And you do not need to abandon your existing website! Instead, your website itself can become part of the social network!

This is a subtle but profoundly important shift in how online publishing can work.

For years, websites have largely been reduced to static endpoints within a platform-dominated internet. Articles are published on self-hosted blogs, but discussion happens elsewhere. Discovery happens elsewhere. Audience building happens elsewhere. The website acts primarily as an archive while social platforms control the actual social layer surrounding the content.

ActivityPub changes this relationship entirely.

Once a website supports federation, it stops being merely a passive destination and starts acting as an active participant in the social web. Users can follow the site directly from Mastodon, Friendica, Misskey or other ActivityPub-compatible platforms. New articles appear natively inside federated timelines. Replies and interactions can flow back into the website itself. Mentions, boosts and conversations become part of a distributed communication layer instead of being trapped inside isolated platforms.

In practical terms, a self-hosted blog suddenly behaves much more like a social media account — without surrendering ownership of infrastructure, domain or content.

This is where the distinction between RSS and ActivityPub becomes particularly important.

RSS already solved content distribution decades ago. Users could subscribe to websites and receive updates without depending on centralized algorithms or platform feeds. But RSS remained largely one-directional. It distributed content, yet social interaction still happened separately on external platforms.

ActivityPub effectively adds a social layer on top of independent publishing.

Followers can interact with posts directly from their preferred Fediverse applications. Conversations can happen across server boundaries. A blog post can travel through the same federated network as a Mastodon post while still remaining fully hosted on the original website.

That fundamentally changes the role of websites within the modern internet.

Instead of functioning as isolated destinations competing for visibility inside platform algorithms, websites can once again become first-class citizens of the social web itself.

This also creates a very different ownership model compared to traditional social media.

On conventional platforms, identity is tightly bound to accounts controlled by platform providers. Audiences are effectively rented. Visibility depends on systems publishers neither operate nor fully understand. A suspended account, policy change or platform collapse can instantly sever access to years of accumulated audience relationships.

A federated website reverses this dependency. The domain becomes the identity, the website becomes the platform and the publisher controls the infrastructure.

Followers may use Mastodon, Friendica, Pixelfed or entirely different Fediverse clients, but the source of truth remains the independently operated website itself.

This architecture also aligns surprisingly well with older ideas surrounding the open web and the IndieWeb movement. Instead of rebuilding the web around increasingly centralized applications, federation allows existing websites to regain social functionality through open standards.

And this is precisely why the WordPress ActivityPub plugin is far more important than it initially appears. It does not simply “cross-post blog articles to Mastodon.” It turns one of the largest publishing systems on the internet into a native participant of the Fediverse.

Why the WordPress ActivityPub Plugin Is Underrated

At first glance, the WordPress ActivityPub plugin does not look particularly revolutionary. It installs like countless other WordPress extensions, adds a handful of federation-related settings and exposes ActivityPub-compatible profile endpoints for authors or the blog itself. Technically speaking, the plugin is relatively lightweight compared to running a full Mastodon instance or operating dedicated Fediverse infrastructure.

And that simplicity is exactly why its broader implications are so easy to underestimate. Because the real significance of the plugin is not what it does for WordPress alone. It is what it potentially does for the web itself.

WordPress still powers a massive portion of the internet. Independent blogs, news sites, company websites, documentation portals and personal publishing platforms all rely on it. If even a small percentage of these websites enabled ActivityPub support, the Fediverse would instantly evolve from a niche ecosystem of dedicated social platforms into something far larger: a genuinely federated social web composed of independently operated websites.

This is fundamentally different from the dominant “build another platform” approach pursued by most social media alternatives.

Instead of requiring users to migrate towards a new centralized destination, the ActivityPub plugin allows existing websites to become social actors directly within their own domains and infrastructure. Publishers retain control over hosting, branding, moderation, archives and URLs while simultaneously participating in federated conversations across the broader Fediverse.

In many ways, this restores an older publishing model that social media gradually displaced.

Before the rise of centralized platforms, blogs themselves were deeply interconnected social spaces. Trackbacks, blogrolls, RSS feeds and comment sections created decentralized networks of discussion distributed across independently operated websites. Social media platforms later consolidated much of this interaction into proprietary timelines and engagement systems controlled by large corporations.

ActivityPub effectively reintroduces a distributed social layer but with modern interoperability standards and significantly broader reach.

And unlike many “decentralized social media” projects, WordPress already solves a problem most federated platforms still struggle with: long-form publishing, like this article here.

Microblogging works well for rapid communication, but websites remain vastly superior for durable content, technical documentation, journalism, tutorials and independent archives. A federated WordPress site combines these strengths with the distribution capabilities of the Fediverse without reducing everything to short-form platform posting.

This architecture also creates meaningful advantages from a privacy and ownership perspective.

A (self-)hosted WordPress installation allows publishers to:

• control their own infrastructure
• define their own moderation policies
• retain ownership over content and media
• avoid platform lock-in
• separate publication from corporate social platforms
• maintain stable identities through their own domains

The Fediverse audience becomes an extension of the website rather than a replacement for it.

That distinction matters because it changes the direction of dependency. Instead of websites relying on platforms for visibility, platforms and Fediverse clients become optional interfaces accessing independently operated publishing nodes.

The plugin also lowers the barrier to federation dramatically. Running a Mastodon server requires dedicated infrastructure, ongoing moderation effort and operational maintenance. Enabling federation for an existing WordPress installation is comparatively trivial. For many publishers, bloggers and self-hosters, this makes ActivityPub adoption realistic without fundamentally changing existing workflows.

Ironically, the WordPress ActivityPub plugin may therefore represent one of the most practical and scalable decentralization projects currently available — precisely because it does not try to replace the web.

It simply allows the web to become social again.

Installing the ActivityPub Plugin

Compared to running a dedicated Mastodon instance, enabling federation for WordPress is surprisingly straightforward. In most cases, an existing WordPress installation can become part of the Fediverse within minutes without requiring major infrastructure changes or entirely new publishing workflows.

The simplest way to get started is installing the official ActivityPub plugin directly through the WordPress plugin directory.

After activation, WordPress automatically exposes ActivityPub-compatible actor profiles and federation endpoints. Depending on the selected configuration, either the entire blog or individual authors can now appear as Fediverse accounts that users can follow from Mastodon, Friendica, Misskey and other compatible platforms.

This fundamentally changes how content distribution works.

Traditionally, publishing a new article required an additional distribution layer. Blog posts had to be manually shared across Twitter, Reddit, LinkedIn or similar platforms in the hope that recommendation algorithms would surface them to an audience. With ActivityPub enabled, WordPress itself becomes part of the social graph. New articles can automatically propagate into the Fediverse without relying on third-party cross-posting tools or centralized social platforms as intermediaries.

Importantly, the website itself remains the primary source of truth throughout this process.

Content is still written and published through the standard WordPress editor. Existing URLs remain unchanged, RSS feeds continue working and the surrounding publishing infrastructure — including themes, plugins, SEO setups and backups — behaves largely as before. ActivityPub simply adds an additional communication layer on top of an independently operated website rather than replacing it with another platform ecosystem.

One particularly elegant feature is that individual WordPress articles themselves become discoverable inside the Fediverse. Users can simply search for the original article URL directly from Mastodon or other compatible platforms and will usually find the post as a federated ActivityPub object within their local Fediverse context. This effectively allows ordinary blog posts to behave similarly to native social media posts while still remaining fully hosted on the original website.

For most self-hosted setups, the technical prerequisites are relatively modest:

• properly configured HTTPS
• working pretty permalinks
• publicly reachable domain
• functioning reverse proxy setup if WordPress runs behind Docker or similar infrastructure

Once the plugin is enabled, WordPress immediately starts exposing Fediverse-compatible profile handles. Depending on the selected federation model, these may look similar to

@blog@example.com

or

@author@example.com

These profiles can then be followed directly from Mastodon and other Fediverse platforms exactly like ordinary social media accounts. New WordPress articles will subsequently appear inside followers’ timelines as federated posts originating directly from the website itself.

Preparing WordPress for Federation

While the ActivityPub plugin itself requires very little configuration, a few parts of the surrounding WordPress setup deserve special attention before enabling federation in production.

The first and most important requirement is a properly functioning HTTPS setup. ActivityPub heavily relies on secure federation between servers and many Fediverse platforms will reject or inconsistently process actors hosted on misconfigured domains. Reverse proxies, TLS termination and certificate renewal should therefore already be working reliably before enabling federation publicly.

Pretty permalinks should also be enabled.

ActivityPub endpoints integrate deeply into WordPress author and post URLs, and the plugin expects clean permalink structures for proper actor discovery and federation handling. A typical configuration using /post-name/ permalinks works well in most cases.

Another important aspect is public reachability.

Fediverse servers need to access various ActivityPub and WebFinger endpoints exposed by WordPress. Installations hidden behind VPNs, broken reverse proxy rules, authentication layers or overly aggressive bot protection systems may fail to federate correctly. This is particularly relevant for self-hosters using Cloudflare, external WAF solutions or restrictive fail2ban setups.

Caching layers deserve careful consideration as well.

Many WordPress installations heavily cache requests through reverse proxies, CDNs or optimization plugins. While normal page caching usually works fine, overly aggressive caching of .well-known endpoints, author JSON responses or ActivityPub routes can create difficult federation issues that are not immediately obvious. ActivityPub endpoints should generally remain dynamically reachable and exempt from unnecessary HTML optimization or transformation layers.

Author configuration inside WordPress also becomes more important once federation is enabled.

Depending on the selected federation model, author display names, biographies, avatars and profile metadata effectively become part of the public Fediverse identity. Empty author profiles or generic usernames tend to look unpolished once exposed through Mastodon and similar platforms. Taking a few minutes to properly configure author metadata significantly improves discoverability and presentation within federated timelines.

Media handling is another area worth reviewing early.

Large image uploads, external object storage, lazy-loading plugins or aggressive image optimization systems can sometimes interfere with how remote Fediverse servers retrieve media attachments. Testing article previews with images from multiple Fediverse platforms helps identify such problems before regular publishing begins.

Finally, it is worth remembering that federation effectively turns parts of a website into public API endpoints.

This introduces slightly different operational considerations compared to a traditional standalone blog. Unexpected spikes in requests from crawlers, federation retries, remote servers or abusive actors become more relevant once a site actively participates in the Fediverse. Proper rate limiting, logging and monitoring therefore become increasingly valuable for production deployments — especially for larger websites or high-traffic environments.

Fortunately, most of these concerns are relatively easy to address with a sane reverse proxy configuration and a moderately hardened WordPress setup.

Webserver and Reverse Proxy Configuration

When WordPress runs behind a reverse proxy, federation only works reliably if the public ActivityPub discovery endpoints are routed correctly to the WordPress backend. The most important endpoints are WebFinger and NodeInfo, both located below /.well-known/.

A minimal NGINX configuration can look like this:

# ActivityPub WebFinger endpoint for WordPress
location = /.well-known/webfinger {
    proxy_pass http://WORDPRESS_BACKEND_IP:WORDPRESS_BACKEND_PORT;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;

    proxy_redirect off;
}

# ActivityPub NodeInfo endpoint for WordPress
location = /.well-known/nodeinfo {
    proxy_pass http://WORDPRESS_BACKEND_IP:WORDPRESS_BACKEND_PORT;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;

    proxy_redirect off;
}

The important part is not the exact backend address, but the routing behavior: requests to /.well-known/webfinger and /.well-known/nodeinfo must reach WordPress unchanged. These endpoints are used by Fediverse servers to discover ActivityPub actors, supported capabilities and federation metadata.

If WordPress itself runs inside Docker and another reverse proxy sits in front of the webserver (oftentimes when using a NAS like Synology), name resolution can become relevant as well. In some setups, WordPress must be able to resolve its own public domain back to the internal reverse proxy or webserver address. This can be handled through extra_hosts in compose.yaml:

services:
  wordpress:
    image: wordpress:latest
    [.......]
    extra_hosts:
      - "example.com:192.168.1.10" # Internal IP of your NGINX reverse proxy

This is especially useful when WordPress or plugins perform requests against the public site URL from inside the container. Without proper internal resolution, those requests may leave the local network unnecessarily, hit the wrong endpoint or fail entirely due to NAT reflection issues.

For production setups, avoid hard-coding public examples blindly. Replace the domain and internal IP address with values matching your own network, and make sure the backend is only reachable from trusted internal systems whenever possible.

Testing Federation with Mastodon and Other Platforms

Once the technical setup is complete, the next step is verifying that the WordPress installation actually federates correctly with the wider Fediverse.

The easiest way to start is searching for the newly exposed ActivityPub profile from an existing Mastodon account. Depending on the selected federation model, this may either be the entire website profile or individual author accounts. You can define and look up the user / blog handle on the AcitivityPub settings Page (for blog handles) or at the WordPress users profile page (if you opt in to use author profiles to populate your articles).

Typical examples look like this:

@blog@example.com

or

@author@example.com

ActivityPub operates asynchronously, and different Fediverse servers process federation queues at varying speeds. Delays of several seconds or even minutes are entirely normal, especially for newly discovered accounts or smaller instances. Initial federation often takes slightly longer because remote servers first need to fetch actor metadata, public keys and profile information.

Testing should therefore include multiple aspects:

• profile discovery
• article discoverability
• image previews
• remote replies
• follower synchronization
• hashtag handling
• media attachments
• updates to edited articles

It is also worth testing from multiple Fediverse platforms instead of relying solely on Mastodon. While Mastodon dominates much of the ecosystem, federation behavior can differ across Friendica, Misskey, Akkoma or Lemmy-based environments. The broader Fediverse remains relatively heterogeneous, and interoperability occasionally exposes subtle implementation differences.

If discovery fails entirely, the problem usually falls into one of a few common categories:

• broken HTTPS configuration
• inaccessible .well-known/webfinger endpoints
• aggressive caching or CDN interference
• incorrect reverse proxy headers
• blocked federation requests
• malformed ActivityPub JSON responses

In practice, most federation issues can be diagnosed quickly by manually testing the WebFinger endpoint directly:

https://example.com/.well-known/webfinger?resource=acct:author@example.com

If this endpoint returns valid JSON and the public website remains reachable from external networks, federation usually works reliably across the broader Fediverse ecosystem.

Behavior of Replies and Reactions

Once discovery works correctly, Mastodon should resolve the profile and display it similarly to any ordinary Fediverse account. At this point, the website effectively becomes followable inside the Fediverse.

Publishing a new article should then automatically generate a federated post visible inside followers’ timelines.

One particularly useful feature of the WordPress ActivityPub plugin is direct article discoverability. Instead of searching only for user handles, users can also search for the canonical article URL itself from Mastodon or other compatible Fediverse platforms as already described above.

For example:

https://example.com/my-article/

If federation works correctly, the article appears as a federated ActivityPub object that users can:

• view
• boost
• favorite
• reply to
• share across the Fediverse

This behavior is especially powerful because it allows ordinary blog articles to participate directly in federated conversations without requiring dedicated social media reposts or manually crafted platform content.

Depending on plugin configuration and moderation settings replies written from Mastodon or other ActivityPub-compatible platforms are federated back to the original website and inserted as native WordPress comments directly below the corresponding article. From the perspective of the website, these interactions are not merely external embeds or screenshots of social media discussions — they become part of the actual discussion layer of the blog itself.

This fundamentally changes the relationship between websites and social platforms. Traditionally, conversations around articles became fragmented across Twitter threads, Reddit discussions, Discord servers or LinkedIn comments, often completely detached from the original publication. Valuable feedback, technical discussions and reader interaction remained siloed inside third-party platforms with no durable connection to the source article. ActivityPub reverses this dynamic.

The discussion can effectively return to the website itself while still remaining distributed across the broader Fediverse. A Mastodon user may reply directly from their preferred client, while the website simultaneously receives the interaction as a native WordPress comment. Depending on the configuration, these federated comments can participate in ordinary comment moderation workflows, notifications and existing WordPress discussion tooling.

Reactions work similarly.

Boosts, likes and other Fediverse interactions can be visualized directly on the article page if the active WordPress theme or additional plugins provide support for displaying these federation events. If not, the ActivityPub Plugin does come with a variety of different widgets which can be used to display interactions on you website nevertheless. In practice, this means the website itself starts exposing social engagement indicators traditionally only visible inside centralized platforms.

The result is surprisingly powerful. The blog regains its role as the primary discussion space while still remaining deeply connected to decentralized social conversations happening across the Fediverse.

Moderation, Replies and Spam Control

Opening a WordPress installation to federation also means opening parts of the website to interactions originating from potentially thousands of external servers. While this is one of the most compelling aspects of ActivityPub, it also introduces entirely new moderation and abuse considerations compared to a traditional standalone blog.

The good news is that the WordPress ActivityPub ecosystem integrates surprisingly well into existing WordPress moderation workflows.

Federated replies arriving from Mastodon or other ActivityPub platforms are typically handled as native WordPress comments. This means existing moderation queues, spam filters, notification systems and comment management tooling continue to work largely as expected. Administrators can approve, reject, delete or moderate federated comments similarly to ordinary local website comments.

This becomes especially important because federation introduces a fundamentally different trust model.

Unlike centralized platforms where moderation is primarily delegated to platform operators, federated websites interact with independently operated servers of varying quality and moderation standards. Some instances are carefully maintained communities, others may be poorly moderated, abandoned or intentionally abusive. A federated WordPress site therefore effectively becomes part of a distributed moderation ecosystem.

In practice, this means moderation should not be treated as an afterthought.

One particularly useful addition is the plugin:

ActivityPub – Auto Approve Replies

You can download it here.

By default, federated replies and reactions often end up inside the WordPress moderation queue before becoming publicly visible. The Auto Approve Replies plugin changes this behavior by automatically approving incoming Fediverse replies and reactions.

This may sound like a small quality-of-life improvement, but in practice it dramatically improves the social experience of a federated blog. Conversations feel substantially more natural when replies from Mastodon or other Fediverse platforms appear immediately instead of being delayed behind manual moderation workflows.

Combined with the native WordPress comment integration, this creates a surprisingly seamless interaction model:

• users reply directly from Mastodon or other Fediverse clients
• replies are federated back to WordPress
• comments appear directly below the original article
• reactions can be visualized on the website itself depending on theme support

The website effectively regains its role as the central discussion space while still remaining connected to distributed social conversations across the Fediverse.

At the same time, automatic approval obviously introduces moderation risks.

Because federated interactions originate from external servers, spam, trolling or abusive content can still become a problem depending on the visibility and reach of the website. Traditional WordPress anti-spam measures therefore remain highly relevant:

• Akismet or alternative spam filtering
• rate limiting
• fail2ban integration
• reverse proxy filtering
• instance-level blocking
• comment throttling

Federation also introduces some unique operational considerations.

Unlike ordinary website comments, federated interactions may originate from remote instances that later disappear, become defederated or change moderation policies entirely. Depending on implementation details, remote avatars, metadata or conversation contexts may therefore behave differently over time compared to purely local comments.

Privacy-conscious administrators should also remember that federated discussions are inherently public and distributed. Depending on the Fediverse platform and caching behavior, replies may simultaneously exist:

• on the originating server
• inside Mastodon timelines
• within remote conversation threads
• and as native comments on the WordPress article itself

This creates a fundamentally different discussion model compared to isolated website comment systems.

Still, this trade-off is precisely what makes ActivityPub-powered WordPress installations so compelling. Discussions no longer disappear into isolated platform silos but instead become part of an open, distributed and independently operated social web.

Choosing the Right Federation Model

One of the first architectural decisions when enabling ActivityPub for WordPress is choosing how the website should appear inside the Fediverse.

The ActivityPub plugin supports two fundamentally different federation models:

• a single federated blog actor
• individual federated author profiles

Both approaches work well, but they create very different experiences for followers, publishers and moderation workflows.

Single Blog Actor

In the single actor model, the entire website appears as one unified Fediverse account:

@blog@example.com

All published articles originate from this single identity regardless of which WordPress author created them internally.

For smaller blogs, personal websites or single-author publications, this is often the cleanest and simplest approach. Followers only need to subscribe to one account, the website maintains a consistent identity across the Fediverse and moderation becomes easier because all interactions are centralized around one actor profile.

This setup also aligns particularly well with traditional blogs where the website itself acts as the primary publisher identity rather than individual contributors.

Another advantage is discoverability.

A single account tends to accumulate followers, boosts and engagement more efficiently because all federated activity strengthens the same profile. For many independent publishers, this creates a clearer and more recognizable presence within the Fediverse ecosystem.

Individual Author Profiles

The second approach exposes individual WordPress authors as separate Fediverse identities:

@alice@example.com
@bob@example.com

Each author effectively becomes their own federated actor with independent followers, timelines and interactions.

This model works particularly well for:

• multi-author blogs
• editorial websites
• magazines
• collaborative publishing platforms
• organizations with multiple public contributors

It also creates a much more personal social experience. Followers can subscribe specifically to authors they care about instead of receiving all content from the entire website.

From a Fediverse perspective, this often feels more natural because users are accustomed to following individual people rather than publications alone.

However, the model also introduces additional complexity.

Moderation becomes more distributed, profile management requires more attention and author metadata suddenly matters significantly more. Display names, avatars, biographies and public author pages effectively become part of each contributor’s Fediverse identity.

Inconsistent author configuration can therefore make federation feel fragmented or unpolished.

Which Model Makes More Sense?

In practice, the decision largely depends on how the website already presents itself publicly.

If the site primarily acts as a unified publication with a strong central identity, the single actor model is usually the better choice. It creates a simpler follower experience and mirrors how many readers already perceive the website itself.

If the publication emphasizes individual authorship and editorial personalities, separate author profiles often integrate more naturally into the social dynamics of the Fediverse.

Interestingly, the single actor model also partially recreates the behavior of traditional social media accounts:
the website itself becomes the account.

The author-profile model, on the other hand, pushes WordPress closer towards a distributed publishing network where individual contributors maintain their own independent social presence directly tied to their domain identity.

Neither approach is objectively superior.

The important part is understanding that federation is not merely a syndication feature. The chosen model fundamentally shapes how the website participates socially inside the broader Fediverse ecosystem.

Fine-Tuning Content Rendering for the Fediverse

One of the most important — and often overlooked — aspects of WordPress federation is how articles are actually rendered inside the Fediverse.

By default, the ActivityPub plugin includes an automatic rendering mode that attempts to decide whether posts should appear as full articles, excerpts or shortened previews depending on the surrounding context. While convenient, the default behavior is not always ideal for long-form publishing.

In practice, posting entire articles directly into Mastodon timelines often clashes with the expectations and reading behavior of most microblogging platforms.

The Fediverse may support long-form content technically, but many users still interact with it primarily through short-form social feeds. Extremely long posts can quickly overwhelm timelines, reduce readability and discourage click-throughs to the original website — which ultimately remains the canonical source of the content.

For most blogs and publishers, using excerpts instead of full article rendering therefore creates a substantially better user experience.

Fortunately, the ActivityPub plugin allows detailed customization of how posts are federated.

The relevant options are somewhat hidden behind the plugin’s advanced configuration mode. To enable them:

• open the ActivityPub plugin settings
• click on “Screen Options” in the top-right corner
• enable “Advanced Settings”

Once enabled, additional federation-specific options become visible inside the settings interface.

One particularly important setting is:

Activity-Object-Type

Combined with the “Post Content” configuration section, this allows precise control over how WordPress articles are rendered inside Fediverse clients.

A practical and highly recommended configuration is using:

• article title
• short excerpt
• canonical permalink
• hashtags

instead of federating the complete article body.

For example:

<strong>[ap_title]</strong>

[ap_excerpt]

🔗 Read the full article here: [ap_permalink]
<br/><br/>
[ap_hashtags]

This creates a much cleaner and more platform-native experience inside Mastodon and other Fediverse clients:

• followers receive a readable preview
• the original website still receives traffic
• discussions remain tied to the canonical article
• timelines stay significantly less cluttered

The approach also aligns better with the broader philosophy of independent publishing.

The website remains the primary destination for long-form content, archival context, media rendering and discussion, while the Fediverse acts as a decentralized distribution and interaction layer surrounding the publication. Another practical advantage is future flexibility.

Fediverse platforms vary significantly in how they render long posts, HTML formatting, media attachments and excerpts. Keeping federated posts relatively lightweight tends to improve compatibility across the broader ecosystem and avoids unexpected formatting problems on smaller or less Mastodon-centric platforms.

In many ways, treating the Fediverse as a social discovery layer rather than a complete replacement for the website itself leads to the best overall publishing experience.

The Challenges of a Federated Web

For all its strengths, the Fediverse is not a magical solution that automatically fixes the structural problems of modern social media.

Federation introduces its own complexities, trade-offs and operational challenges — especially once websites themselves become active participants in distributed social networking.

This is important to acknowledge because discussions around decentralization often drift into overly idealistic territory. In practice, the Fediverse remains a heterogeneous ecosystem composed of independently operated servers, different software implementations and communities with wildly varying moderation philosophies.

That diversity is both its greatest strength and one of its biggest challenges.

One of the most noticeable differences compared to centralized social platforms is discoverability.

There is no single global recommendation algorithm aggressively optimizing engagement across the entire network. Content distribution depends far more heavily on:

• follower relationships
• boosts and shares
• hashtags
• local community discovery
• cross-instance federation behavior

For independent publishers accustomed to platform-driven reach amplification, this can initially feel limiting. Growth inside the Fediverse is often slower, more organic and more community-oriented than on traditional social media platforms.

Moderation also becomes substantially more decentralized.

On centralized platforms, moderation decisions are usually delegated to corporate trust-and-safety teams — however imperfect those systems may be. In the Fediverse, moderation responsibilities shift much closer towards instance administrators and individual website operators themselves.

This creates both opportunities and operational burdens.

Communities gain the ability to define their own moderation rules and federation boundaries, but administrators also inherit the responsibility of dealing with spam, abuse, harassment and problematic remote instances directly. Defederation, blocklists and local moderation policies become part of the operational reality of running a federated presence.

Technical fragmentation introduces additional complexity.

Although ActivityPub provides a shared protocol layer, different Fediverse platforms implement federation slightly differently. Mastodon compatibility is generally excellent because it dominates much of the ecosystem, but interoperability edge cases still exist across the fediverse.

Features such as quote-posting, content formatting, media rendering or threaded conversations may behave differently depending on the remote platform involved.

The user experience can also feel comparatively rough around the edges.

Centralized social media companies invest enormous resources into onboarding, recommendation systems, moderation tooling and interface optimization. The Fediverse, by contrast, often prioritizes openness and interoperability over frictionless user experience. Concepts like federation, instances, remote follows or WebFinger discovery still confuse many mainstream users unfamiliar with decentralized systems.

And finally, there is the question of sustainability.

Running independent infrastructure requires time, moderation effort and ongoing maintenance. Federation works precisely because it distributes responsibility across many independent operators — but that also means the ecosystem depends heavily on volunteers, self-hosters and smaller organizations willing to maintain parts of the network themselves.

Yet paradoxically, many of these limitations are directly connected to what makes the Fediverse valuable in the first place.

The absence of a central authority means no single company controls the network.
The absence of engagement algorithms reduces incentive structures built around outrage optimization.
The distributed architecture makes the ecosystem substantially harder to monopolize or capture politically and commercially.

Federation trades convenience and centralized efficiency for openness, resilience and autonomy.

And while the Fediverse may never fully replicate the frictionless scale of corporate social media platforms, it offers something increasingly rare on the modern internet:
the possibility for websites, communities and individuals to participate in social networking without surrendering ownership of identity, infrastructure and communication channels to a handful of dominant technology companies.

Conclusion — Owning Your Audience Again

For years, the web gradually moved away from independently operated websites towards increasingly centralized social platforms. Publishing remained technically decentralized, but visibility, interaction and audience relationships became concentrated inside ecosystems controlled by a small number of corporations.

The result was a strange inversion of the original web. People still owned domains and websites, yet increasingly depended on external platforms to actually reach anyone.

ActivityPub offers a fundamentally different direction.

Instead of building yet another closed platform competing for user lock-in, federation turns social interaction itself into an open protocol layer. And once social networking becomes protocol-based rather than platform-based, websites can participate directly again.

This is precisely what makes the WordPress ActivityPub plugin so compelling.

It does not ask publishers to abandon their websites in favor of another platform. It does not require migrating entire communities into new proprietary ecosystems. And it does not replace existing publishing workflows with an entirely different social media stack.

Instead, it allows websites to become social actors themselves. A WordPress installation can suddenly participate directly in the Fediverse, expose followable identities for blogs or individual authors and distribute newly published articles across decentralized timelines without relying on centralized social media platforms as intermediaries. Replies from Mastodon and other ActivityPub-compatible platforms can flow back into the website itself, where federated discussions become integrated into native WordPress comments. At the same time, the entire system remains fully self-hosted and independently operated, allowing publishers to retain complete control over infrastructure, content and audience relationships.

In many ways, this feels less like inventing a new web and more like restoring capabilities the web gradually lost during the platform era.

Of course, federation introduces trade-offs. Moderation becomes more distributed, interoperability remains imperfect and the Fediverse still lacks much of the polish and convenience associated with centralized platforms. Running independent infrastructure also requires responsibility and ongoing maintenance.

But these imperfections are closely tied to the core idea itself which is that no single company owns the network.

And at a time when social platforms become increasingly unstable, algorithmically controlled and intertwined with AI-driven abstraction layers separating users from original sources, that distinction matters more than ever.

The future of the social web may not belong to platforms at all. It may belong to protocols, independent websites and people willing to operate their own corners of the internet again.