AT Protocol vs ActivityPub: Which Federation Protocol Should Your WordPress Community Use?

Two open protocols are reshaping the social web in 2026. ActivityPub powers Mastodon, Threads, Lemmy, PeerTube, and the broader fediverse, a network of hundreds of millions of users across thousands of independent servers. AT Protocol powers Bluesky and its growing ecosystem of applications including WhiteWind, Smoke Signal, and frontpage.fyi, a newer network that hit 42 million users in early 2026 and is growing fast.

Both protocols are genuinely open. Both are designed to move power away from centralized platforms toward users and operators. Both matter for WordPress community builders who want to connect their sites to the open social web.

But they make different architectural choices, serve different use cases well, and have very different levels of WordPress integration available today. This post breaks down the comparison across the dimensions that actually matter for a community operator and gives you a clear verdict on which one to use now.

The Core Architecture Difference

Understanding the two protocols requires understanding one foundational difference: where identity lives.

In ActivityPub, your identity is tied to a server. Your handle is @[email protected]. If your server shuts down, your identity is gone. You can migrate to another server and notify your followers of the new address, but the migration is manual and your old content does not travel with you. Your identity is as portable as your server operator allows it to be.

In AT Protocol, your identity is a Decentralized Identifier (DID) that you own independently of any server. Your handle can be a domain you control (like yourname.com) which resolves to a DID. Your data lives in a Personal Data Server (PDS) that you can host yourself or delegate to a provider. If your PDS shuts down, you take your DID and your data and move to a new PDS. Continuity is built into the protocol.

This is a meaningful difference for long-lived communities. A community built on AT Protocol can survive the shutdown of its hosting provider intact. A community built on ActivityPub depends on the availability of its instance.

Identity and Portability: Detailed Comparison

ActivityPub Identity

ActivityPub uses WebFinger for identity discovery. Your actor profile lives at a URL on your server. Followers from other servers subscribe to that URL. When they request your profile, their server fetches it from yours.

For a self-hosted WordPress site using the ActivityPub plugin, this works well: your site is your server, your domain is your identity, and you own both. The portability problem is more acute for people using hosted ActivityPub instances (mastodon.social, fosstodon.org, and similar) where they do not control the server. For WordPress operators running their own installation, ActivityPub identity is reasonably portable as long as you keep your domain.

AT Protocol Identity

AT Protocol uses DIDs, specifically the did:web and did:plc methods. A did:web DID is anchored to a domain you own. A did:plc DID is anchored in a public ledger maintained by the AT Protocol network. Either way, the DID is portable independently of any specific server.

Your handle can be any domain you control. If you own yourcommunity.com and set up the AT Protocol DNS records, your handle becomes yourcommunity.com. Your followers follow a DID, not a server URL, so changing your PDS provider does not break their subscriptions.

This is genuinely superior for long-term data ownership. The tradeoff is complexity: setting up your own PDS is a more involved process than installing a WordPress plugin.

Data Model and Content Portability

ActivityPub Content

ActivityPub content is distributed. When you post something, copies of it are delivered to the inboxes of your followers’ servers. There is no single canonical copy of your content beyond what lives on your own server. If you want to export and move your posts, you export from your own server. Migration tools for ActivityPub instances exist but they are imperfect, especially for large post histories.

For WordPress, this means your posts are already in your WordPress database. There is nothing to migrate because your WordPress site is the canonical source. This is actually one of the arguments for using WordPress as your ActivityPub server rather than a hosted Mastodon instance, your data never leaves your own infrastructure.

AT Protocol Content (the Repository Model)

AT Protocol uses a repository model. All your content lives in a cryptographically signed repository on your PDS. Each record (post, like, follow, block) is addressed by a stable URI that includes your DID. The repository can be fully exported as a CAR file and imported to any new PDS.

This is more complete portability than ActivityPub offers. Your entire social graph, post history, and interaction records travel with you when you change providers. The cryptographic signing also means anyone can verify that content attributed to your DID actually came from you.

The drawback is that the repository model requires more infrastructure. A PDS is not just a database, it is a crawlable, cryptographically consistent data store with specific API requirements. Running your own PDS is a non-trivial operation compared to running a WordPress site with the ActivityPub plugin.

Moderation Models

ActivityPub Moderation

ActivityPub moderation is primarily instance-level. Server operators set the rules for their instance, block other instances they do not want to federate with, and remove content that violates their policies. There is no protocol-level content moderation, each server makes its own decisions.

This creates a patchwork. Some instances block others over policy disagreements. Users on different instances see different versions of the network. For community operators running their own WordPress installation, this means you control your own moderation entirely, which is the setup you want.

AT Protocol Moderation (Labelers)

AT Protocol introduced a composable moderation model called Labelers. A labeler is an independent service that applies labels to content and accounts. Users and app developers choose which labelers to subscribe to. A single piece of content can have labels from multiple labelers, and different clients can display or hide content based on those labels.

This is architecturally more sophisticated than ActivityPub’s instance-level blocking. A specialized labeler for, say, legal threats or coordinated harassment can be subscribed to by any Bluesky client or AT Protocol app. Community operators can run their own labeler to enforce community-specific rules without blocking federation with the broader network.

In practice, for 2026 deployments, ActivityPub’s moderation model is mature and well-understood. AT Protocol’s labeler system is newer and the tooling is still developing. Both are viable; the AT Protocol approach has a clearer path to sophisticated cross-community moderation at scale.

Ecosystem Size and WordPress Integration

Dimension	ActivityPub	AT Protocol
Total users (est. mid-2026)	360M+ (Threads 350M, Mastodon 10M+)	42M+ (Bluesky)
WordPress plugin	Official plugin, 30K+ installs, actively maintained	Community plugins, experimental
Setup complexity for WP	Install plugin, configure, done	DNS records + PDS setup or community bridge
Incoming replies as comments	Supported in current plugin	Not available for WordPress yet
Major apps	Mastodon, Threads, Lemmy, PeerTube, Pixelfed	Bluesky, WhiteWind, Smoke Signal, Acorn
Community/forum use cases	Lemmy (federated forums) + custom	Acorn (communities), early stage

The ecosystem size difference is significant. Threads alone has 350 million users on ActivityPub. A post from your WordPress site that gets traction on Threads can reach an audience that AT Protocol cannot currently match. For pure distribution reach in 2026, ActivityPub wins by a large margin.

The WordPress integration gap is equally significant. The official ActivityPub plugin for WordPress has a full-time team, detailed documentation, and an established upgrade path. AT Protocol WordPress integration is at the experimental stage, there are community-built bridges and plugins, but nothing with the stability and support of the ActivityPub plugin.

Three Architecture Options for WordPress Communities

Architecture 1: Pure ActivityPub (Recommended for Most)

Install the WordPress ActivityPub plugin. Configure author and blog actor modes. Publish posts and watch them federate to Mastodon, Threads, and Lemmy followers. Incoming fediverse replies appear as WordPress comments.

This is the right choice if your goal is maximum reach today, minimum setup complexity, and a mature, supported integration. The tradeoff is that your identity is tied to your domain (acceptable if you own your domain long-term) and content portability depends on your WordPress database.

Best for: communities that want to publish to the open social web now with minimal friction. Any BuddyPress site, any WordPress blog, any community with public content.

Architecture 2: Pure AT Protocol (Forward-Looking)

Set up a PDS at a subdomain of your community domain (pds.yourcommunity.com). Use the official AT Protocol PDS distribution from Bluesky. Assign DIDs to your community members. Publish content to your PDS and let it crawl to the AT Protocol relay network.

This gives you maximum data portability and the most sophisticated identity model. It does not currently integrate with WordPress in a turnkey way. Running a PDS requires server administration skills and ongoing maintenance comparable to running a mail server.

Best for: technically advanced operators who prioritize long-term data sovereignty and are willing to invest in infrastructure now for a protocol that will mature over the next 2 to 3 years. Open source projects, developer communities, and organizations with dedicated infrastructure teams.

Architecture 3: Hybrid Bridge

Run both. Use the ActivityPub plugin for WordPress-to-fediverse publishing (reaching the 360M ActivityPub user base). Separately, maintain a Bluesky presence where posts from your WordPress site are cross-posted via a bridge service or a custom webhook. Track engagement on both networks and let audience behavior inform which protocol to invest in more deeply over time.

The hybrid approach is the lowest-risk path for operators who are uncertain. ActivityPub does the heavy lifting now. AT Protocol builds an audience for when the ecosystem matures. The cost is operational complexity, you are managing two federation channels instead of one.

Best for: content-forward communities, publishers, and media sites that want presence on both networks without committing to one protocol architecture. The cross-posting can be automated with n8n or Make, keeping the operational overhead manageable.

Which Protocol Should You Bet On?

For publishing, getting your content in front of people on open social networks, ActivityPub is the clear choice today. The audience is 8x larger, the WordPress integration is production-ready, and the setup takes 10 minutes. If you are not on ActivityPub yet, that is where to start.

For community use cases specifically, forum discussions, member interactions, Q&A threads, ActivityPub is currently the only option with any practical tooling. Lemmy implements ActivityPub for federated forums. There is no equivalent AT Protocol application in production for community use as of mid-2026.

AT Protocol deserves attention for three reasons. First, Bluesky’s growth trajectory suggests it will continue to gain users, and the communities forming there are often technically sophisticated early-adopter audiences. Second, the data portability model is genuinely better for long-term ownership. Third, the ATmosphere (the ecosystem of apps beyond Bluesky itself) is developing rapidly, Acorn in particular is building community features directly on AT Protocol.

The honest answer is: implement ActivityPub now because the tooling is ready and the audience is there. Build awareness of AT Protocol and revisit the WordPress integration question in 12 to 18 months. By then, the community-use-case tooling for AT Protocol will likely be mature enough to make a real comparison.

The worst decision is to wait for the protocol question to resolve before doing anything. ActivityPub federation on WordPress has essentially no downside for a community that publishes public content. The infrastructure cost is a single free plugin. Start there today and keep watching the AT Protocol space as it develops.

If you want to go deeper on the ActivityPub setup for BuddyPress, the step-by-step guide covers the full configuration. If you are technically inclined and want to explore AT Protocol PDS hosting for your community, get in touch, we are following that development closely and can scope what a forward-looking federation architecture would look like for your specific setup.