ActivityPub for WordPress

This post isn’t about the ActivityPub plugin. ATmosphere is a separate plugin from the same small team, for the other half of the open social web: the AT Protocol, the open network behind Bluesky. We’re posting about it here because the audience overlaps and the mission is the same. If there’s enough interest, we’ll spin up a dedicated blog for it. Until then, this is the closest venue.

Today is the public 1.0.0 release on WordPress.org. After months of design notes, internal experiments, and a stretch of focused work alongside the ActivityPub plugin, ATmosphere has cleared the troposphere.

When you publish a post, ATmosphere shares it on Bluesky and stores the full article on your AT Protocol account as a structured record. Bluesky replies, likes, and reposts come back as comments on your WordPress post. Approved comments from logged-in readers go the other way and appear as replies under your original Bluesky post. The same conversation lives in both places without you having to copy anything by hand.

The bet underneath is bigger than cross-posting. ATmosphere publishes site.standard.* lexicon records, so your blog itself becomes AT Protocol data, not just a link shared on Bluesky. Any compatible app can read the full article from your AT Protocol account, the same way it reads a Bluesky post. WordPress becomes a first-class participant in the network, not a visitor.

The first question you may have is: how is this different from Jetpack Social’s Bluesky integration, or from any of the other plugins that share to Bluesky?

The answer is that they’re solving a different problem. A cross-poster gets your content in front of Bluesky users, which is a real and useful thing. But it’s still a broadcast model. Your WordPress site talks at Bluesky, it doesn’t participate in the protocol.

In practice that shakes out two ways. First, a cross-posted update creates a copy, not a connection. The post on Bluesky and the post on WordPress are separate records, and nothing in the protocol ties them together. Second, your blog itself has no identity in the network. The cross-poster authenticates as you, the person, and posts on your behalf. Your blog as an entity, with its archive and structure, is invisible to the protocol.

ATmosphere is built around making your blog itself a participant. Every publish writes two records: an app.bsky.feed.post so the update shows up in Bluesky timelines, and a site.standard.document from the standard.site lexicons that stores the full canonical article on your AT Protocol account. A bskyPostRef link ties the two together. Your blog appears in the network as a publication that other apps and aggregators can discover and read in full, not as a stream of truncated link cards.

If you want a poster, Jetpack Social is the right tool. If you want your WordPress site to be a place on the AT Protocol, that’s what ATmosphere is for.

There’s a natural follow-up once the model clicks: if my WordPress site is acting as a Bluesky identity, why does Bluesky (or another provider) still need to be in the picture at all? Why not host the data on the site itself?

We tried that route first. About 90% of a Personal Data Server (the AT Protocol service that holds your signed records and streams them to the network) maps cleanly to PHP and a WordPress database. The remaining 10% is the firehose: a WebSocket stream that pushes every change to the network’s relays in real time. PHP’s request-response model is fundamentally incompatible with persistent connections like that, and typical WordPress hosting environments aren’t designed for always-on background processes either.

The cleaner mental model turned out to be email. Even when you self-host your mail, you don’t build the mail server as a WordPress plugin. The mail server is its own piece of infrastructure that runs alongside your site. AT Protocol is the same shape. The PDS is infrastructure, not application logic. ActivityPub was designed to be implementable by any HTTP server, which is why it works as a plain WordPress plugin. AT Protocol was designed around always-on data servers, so the natural fit is a hosted PDS running next to WordPress, not inside it.

For 1.0.0, that means using whichever PDS the user already has. Most people connecting ATmosphere come in with a Bluesky account, so they already have a PDS and a DID, and borrowing that lets us focus on the parts that live on the WordPress side: the publishing pipeline, the long-form rendering, the comment round trip, the domain-as-handle handshake.

We are still pulling on a thread, though. There’s a version of this where a PDS sits comfortably alongside WordPress, ready to host your records for you, so the AT Protocol side feels just as native to WordPress as the ActivityPub side already does. Nothing to announce yet. We’ll let you know when there’s something to show 😉

One of the headline features: your WordPress domain becomes your Bluesky handle. Instead of @you.bsky.social, your handle reads @yourblog.com.

ATmosphere handles the verification side. It serves the right file at /.well-known/atproto-did so Bluesky can confirm the domain really belongs to you. From the settings page, it’s one click. You then open Bluesky, pick Change Handle, choose I have my own domain, enter your site, and you’re done. Same identity model Bluesky uses for its own custom domains, but the technical bit takes care of itself.

The hardest problem in WordPress-to-Bluesky publishing is what to do with a long article on a 300-character network. ATmosphere gives you three options from the settings page:

• A link card, the default. A clean preview pointing back to your full post.
• A single post combining the body text and the permalink, for when the post fits.
• A two-post teaser thread: a hook, a body chunk, and a “continue reading” reply with the link card. The teaser surfaces reliably on bsky.app profiles, and the terminal post always offers a clear path back to the full article on your site.

When you edit a threaded post, ATmosphere updates the existing Bluesky posts in place when it can, so links and replies stay connected. If you change the publishing format, ATmosphere replaces the old posts with new ones. And the full article, every paragraph of it, lives on your AT Protocol account regardless of which format you pick, so other AT Protocol-aware apps and readers can render the long version too.

When someone replies, likes, or reposts your post on Bluesky, ATmosphere checks periodically and turns those reactions into WordPress comments on the matching post. Likes and reposts get their own comment types, so they show up as engagement counts rather than duplicating as text comments.

Going the other way: when a logged-in reader leaves an approved comment on a cross-posted article, it’s published to Bluesky as a reply under your original post. Edits sync. Unapprove or delete, and the corresponding Bluesky reply comes down too. Anonymous comments, trackbacks, and pingbacks are skipped. Only logged-in readers participate in the round trip.

• Backfill. A built-in tool publishes older posts to AT Protocol on demand, batched to ten at a time so it doesn’t overwhelm your server.
• Post types. Choose which post types publish to AT Protocol from the settings page. Plugins and themes can opt their own custom post types in with add_post_type_support( 'your_type', 'atmosphere' ).
• Extensible. New atmosphere_publish_post_result and atmosphere_publish_comment_result actions let other code react to publish success or failure. An atmosphere_should_sync_reply filter lets you suppress specific incoming replies before they become comments.

Download from WordPress.org or grab the source on GitHub.

This blog has always been about the ActivityPub plugin, and ATmosphere is a different plugin for a different protocol, so this post is something of a guest appearance. If readers tell us they want ongoing release posts, deep dives, and roadmap notes about ATmosphere too, we’ll spin up a dedicated home for it. For now, follow along here and let us know.

A huge thank-you to everyone who shaped 1.0.0, especially Brandon Kraft (@kraft@religious.social) and Ryan Cowles, who carried huge pieces of the onboarding, settings, and publishing work over the last few months. Thanks also to the AT Protocol and Bluesky folks who’ve been generous with their time on the lexicon questions.

Try it out, point your domain at Bluesky, publish a post, and tell us what you think. What should ATmosphere do next?

Every major version is a milestone, and 8.0.0 is no exception. Your WordPress blog just became a two-way street in the Fediverse. Visitors can like and boost your posts directly on your site. Media from federated replies is handled more reliably, and new block patterns make it easy to drop ActivityPub features into your pages.

The Fediverse Reactions block now has optional Like and Boost action buttons, inline with each reaction group. When a visitor clicks one, a modal opens where they can enter their Fediverse handle or copy the post URL to interact from their home server.

The plugin remembers the visitor’s profile in their browser, so the second time around it’s even faster. And for folks who aren’t familiar with how the Fediverse works, each modal now includes a collapsible “Why do I need to enter my profile?” help section that explains the open social web in plain language.

This dramatically lowers the friction for cross-platform engagement.

Setting up a Fediverse-ready profile page used to mean manually assembling Follow Me, Extra Fields, and Followers blocks. Not anymore.

We’ve added a “Fediverse” block pattern category with four pre-configured layouts:

• Author Profile with Follow, a compact profile card.
• Fediverse Follow Page, a full-page follow experience.
• Author Header with Follow, great for author archive headers.
• Fediverse Sidebar, drop it into any sidebar or widget area.

If you’re running a block theme on WordPress 6.7+, there’s also a new Author Archive (Fediverse) block theme template ready to go.

A new pre-publish panel now analyzes your post content and suggests an appropriate post format when your object type is set to “Post Format.” Got a post that’s mostly images? It’ll nudge you toward the Image format. A video post? Video format.

This matters because media-focused Fediverse platforms like Pixelfed and Vernissage display Notes differently than Articles, so choosing the right format means your content looks its best everywhere it lands.

We’ve added a snippets/ folder to the GitHub repository, a home for lightweight, community-contributed extensions that don’t belong in the core plugin but are too useful to lose. The first batch includes:

• FediBlog Tag, automatically adds #FediBlog to standard blog posts for better Fediverse discovery.
• Locale from Tags, derives post locale from taxonomy tags.
• Bot Account, marks your profile as automated and displays a “BOT” badge in the Fediverse.
• Blockless ActivityPub, renders Fediverse reactions as pure server-side HTML, no JS required.
• Photon CDN, serves cached remote media through Jetpack’s Photon CDN for faster delivery.

Got a snippet of your own? Check out the snippets folder and send a PR.

Under the hood, we’ve rebuilt how the plugin handles remote media, avatars, emoji, images, audio, and video from across the Fediverse. Instead of importing everything into the WordPress Media Library at insert time, media is now wrapped in custom blocks and cached lazily at render time.

What does that mean for you? Faster processing of incoming content, less disk usage, and better rendering of audio and video attachments. Original remote URLs are preserved in block attributes, so caches can be regenerated without data loss. If you’re using Jetpack’s Site Accelerator, that works too, the new system is built filter-first.

For site admins, there are new CLI commands to keep things tidy:

wp activitypub cache status
wp activitypub cache clear

With WordPress 7.0 deprecating PHP 7.2 and 7.3, we’ve raised the minimum requirement to PHP 7.4. This lets us clean up compatibility polyfills and use more modern PHP features going forward. If you’re still on an older version, update your PHP before updating the plugin.

• Add a help section to interaction dialogs explaining the Fediverse and why entering a profile is needed.
• Add a notice on the Settings page to easily switch from legacy template mode to automatic mode.
• Add a pre-publish suggestion that recommends a post format for better compatibility with media-focused Fediverse platforms.
• Add a Site Health check that warns when plugins are causing too many federation updates.
• Add backwards compatibility for the ACTIVITYPUB_DISABLE_SIDELOADING constant and activitypub_sideloading_enabled filter from version 7.9.1.
• Add bot account snippet that marks ActivityPub profiles as automated accounts, displaying a “BOT” badge on Mastodon and other Fediverse platforms.
• Add Cache namespace for remote media caching with CLI commands, improved MIME validation, and filter-based architecture.
• Add federation of video poster images set in the WordPress video block.
• Add Locale from Tags community snippet.
• Add optional Like and Boost action buttons to the Fediverse Reactions block, allowing visitors to interact with posts from their own server.
• Add pre-built Fediverse block patterns for easy profile, follow page, and sidebar setup.
• Add snippet for blockless fediverse reactions.
• Add wp activitypub fetch CLI command for fetching remote URLs with signed HTTP requests.

• Improved active user counting for NodeInfo to include all federated content types and comments.
• Improve language map resolution to strictly follow the ActivityStreams spec.
• Superseded outbox activities are now removed instead of kept, reducing clutter in the outbox.
• The minimum required PHP version is now 7.4.

• Accept incoming activities from servers that use standalone key objects for HTTP Signatures.
• Fix a crash on servers where WordPress uses FTP instead of direct file access for media caching.
• Fix a crash when receiving posts from certain federated platforms that send multilingual content.
• Fix automatic cleanup of old activities failing silently on sites with large numbers of outbox, inbox, or remote post items.
• Fix comment count to properly exclude likes, shares, and notes.
• Fix follow button redirect from Mastodon not being recognized.
• Fix modal overlay not covering the full screen on block themes.
• Fix outbox invalidation canceling pending Accept/Reject responses to QuoteRequests for the same post.
• Fix QuoteRequest handler to derive responding actor from post author instead of inbox recipient.
• Fix reactions block buttons inheriting theme background color on classic themes.
• Fix reactions block layout on small screens and remove unwanted button highlight when clicking action buttons.
• Fix signature verification rejecting valid requests that use lowercase algorithm names in the Digest header.
• Fix soft-deleted posts being served instead of a tombstone when the post is re-saved.
• Improve compatibility with federated services that use a URL reference for the actor’s public key.
• Improve handling of all public audience identifiers when sending activities to followers and relays.
• Prevent private recipient lists from being shared when sending activities to other servers.

Download from WordPress.org or grab it on GitHub. Remember to check your PHP version first — 7.4 or higher is now required.

A huge thank you to everyone who contributed code, testing, bug reports, and ideas to this release. Special thanks to @kraft@religious.social, @jeremy, and @futtta@mastodon.social for their snippet contributions.

Update, try out those Like and Boost buttons, and let us know what you think — what’s the feature you’ve been waiting for? What would you like to see next?

This post is about work happening on WordPress.com, specifically the Reader, the long-running subscription-and-reading surface that’s been part of WordPress.com since 2008. It’s a sibling effort to the ActivityPub plugin, not a feature of it. We think it matters to plugin readers anyway, because the two pieces are converging, and the converging point is what we’ll be working on next.

Two weeks ago, Automattic kicked off something internally called Radical Speed Month, a four-week sprint where small teams ship fast on focused projects. We (@jeremy and @pfefferle@mastodon.social) took the chance to spend it on something that’s been sitting at the edge of the Fediverse-and-WordPress conversation for a while: making the WordPress.com Reader speak Fediverse.

Today is roughly the halfway mark, and the picture is clearer than we expected. Here’s what shipped, what’s in flight, and what’s still ahead.

The Reader on WordPress.com has held a single, useful role for over a decade: it’s where your subscriptions live. Blogs, podcasts, RSS feeds. What it hasn’t done, yet, is read the open social web. Your Mastodon timeline lives in another app. Your Bluesky timeline lives in a third. The Fediverse is out there, and the Reader stays over here.

The Radical Speed Month bet: ship three protocol adapters in four weeks, and prove the Reader can become a universal aggregator. RSS / Google Reader API (so any reader app can use WordPress.com as a sync backend), ActivityPub (so Mastodon, Pixelfed, and friends show up natively), and ATProto / Bluesky (because that’s where a real chunk of the social-web conversation has gone). One Reader, every protocol you care about.

If you’ve been following the ActivityPub plugin for a while, you already know one half of this story, your blog speaking out to the Fediverse. The other half is reading in, and that’s where this month’s work concentrates.

Any Google Reader-compatible app can now point at WordPress.com and use it as a sync backend. That includes Reeder, NetNewsWire, ReadKit, lire, Unread, Fiery Feeds, Feed Me, and Read You. The auth onboarding is short, and your subscriptions, read state, and stars sync across whichever app you actually like. We’re working on a setup guide that walks through the steps for the most common apps; it should land soon.

This wasn’t directly Fediverse work, but it’s part of the same idea: the Reader as a backend, not a destination. If your reading habit lives in a different app, that’s fine. Your subscriptions still live on WordPress.com.

The Bluesky / ATProto adapter has moved further than the original plan suggested.

You can:

• Connect a Bluesky account through the Reader’s connections panel, with a Verify step that confirms the handshake works on both sides.
• Read your Bluesky home timeline as a tab in the Reader, with native rendering for facets, embeds, and quote posts.
• Follow links inward, opening a thread in the Reader, viewing an author’s profile, browsing their posts / replies / media filter tabs, following a hashtag.
• Follow and unfollow Bluesky accounts directly from the profile pages.
• Like posts, repost posts, and reply to posts. A shared composer for replies is in late review.

The remaining piece on the Bluesky side is quote-posting and deleting your own posts, which we’re shipping together. After that, Bluesky is a complete first-class tab in the Reader.

Mastodon followed the same pattern: connect, verify, then a steady cadence of small additions like timeline, in-app threads, author profile and feed (with Posts / Replies / Media filter tabs), and tag and hashtag feeds. All of those are live for Mastodon today.

What’s still coming on the Mastodon side is the equivalent of the Bluesky interaction work (favourite, boost, reply, quote) built on the same shape that worked for Bluesky. Expect those to land in the second half of this month.

If you read 8.1.0 — By the Numbers, you’ll have noticed a small line in the announcement: the plugin now exposes an ActivityPub API. It’s experimental, behind a feature flag, and lets third-party apps create, edit, and delete posts on your blog the way they would post to a Mastodon account.

That work isn’t an accident. It’s one half of a bridge, and Radical Speed Month is the other half.

The Mastodon-in-Reader work that shipped this month is user-level: you connect your Mastodon account once, and the Reader can sync your Mastodon timeline regardless of where your blog lives. That’s a useful starting point, but it’s not the only path forward. The model we’ve been working toward for a year is blog-level: each ActivityPub-enabled WordPress blog as its own social identity inside the Reader, with the plugin providing the actor and the ActivityPub API providing the connection.

That work is on the schedule for the second half of the month. The radical-speed pace gave us proof first: timelines, threads, profiles, and interactions can all run through one shared pattern, with two networks already validating it. With the pattern in place and the plugin’s ActivityPub API ready to talk to, the blog-level path slots into the same architecture, letting your plugin-enabled blog appear as an ActivityPub identity in the Reader sidebar, with its inbox, its outbox, and its real ActivityPub follow graph. And because the API is part of the ActivityPub standard, the same path works for any Reader or client that speaks it, not just WordPress.com.

A short list of what we’re chasing for the second half of the month and just past it:

• Quote-posting and delete-your-own-post for both Bluesky and Mastodon, the last pieces of the interaction set.
• A shared composer that handles replies, quote-posts, and standalone posts across networks. Already in progress on the Bluesky side; Mastodon plugs in next.
• Disconnect, a clean way to remove a Mastodon or Bluesky connection from the Reader.
• Blog-level ActivityPub, the design pass and first slices for plugin-enabled blogs as first-class Reader identities. The user-level work proved the pattern; this is where the plugin and the Reader actually meet.
• Tightening the shared pattern so adding the next network (Threads, Pixelfed, whatever comes after) is incremental work.
• Wrap-up, a metrics snapshot, an honest retrospective, and the heads-up notes our customer-support folks need before the work goes broad.

A month feels short to ship three protocols’ worth of reading, profiles, and interactions. It’s worth saying out loud: this didn’t happen because we worked unsustainable hours. It happened because we sat with the design for months, picked a shape that lets each protocol reuse the same plumbing, and broke the work into pieces small enough that any one was reviewable in a day or two. “Radical speed” turned out to mean: a backlog of careful design, drained quickly.

If you run an ActivityPub-enabled WordPress blog, whether on WordPress.com or self-hosted, the practical takeaway is small for now and meaningful soon. The plugin’s ActivityPub API in 8.1.0 is the foundation for your blog showing up as a real social identity inside any Reader or app that speaks the same protocol. The WordPress.com Reader is the first concrete target, but the universality matters: any client that implements the standard can talk to your plugin-enabled blog the same way.

Already, the work this month means there’s now a Reader on WordPress.com that knows how to read the Fediverse alongside RSS and Bluesky. That’s a meaningful thing to have built, and the bridge from your plugin-enabled blog to that Reader is what the second half of the month is about.

We’ll keep posting updates as the month closes out. If you have thoughts on what blog-level ActivityPub in the Reader should look like, what protocols you’d want next, or how the plugin’s ActivityPub API should evolve to make this seamless, leave a comment on the plugin’s GitHub repository or reply on the Fediverse. We read every message.

If 8.0.0 opened the Fediverse up as a two-way street, 8.1.0 helps you see and share what travels down it. A new Fediverse statistics feature leads the release, with a dashboard widget, email reports, and a shareable stats block. Alongside it: a new ActivityPub API that lets third-party Fediverse apps post to your blog, Starter Pack imports, and richer image metadata for photographers.

The headline work this release is a brand-new Fediverse statistics feature, three connected pieces that finally let you see (and share) how your site is doing on the open social web.

When you log into your WordPress admin, there’s now a Fediverse Stats widget on the dashboard.

It’s built around three things:

• Stat highlights: followers, posts, and engagement counts, with a comparison to the previous period so you can tell if the line is going up or down.
• A monthly engagement chart: an interactive SVG line chart of engagement over time.
• Top supporter and top posts: the people most engaged with your blog, and the posts that travelled furthest.

If you have both a user actor and a blog actor enabled, a selector lets you switch between them.

Not everyone logs into wp-admin every day, so the plugin can now also email you your stats.

There are two report types:

• Annual reports, a wrap-up of your year on the Fediverse. On by default.
• Monthly reports, a smaller recap for the previous month. Opt-in, for the folks who like a regular pulse check.

Both are delivered through the WordPress email system and available as notification preferences, so you can turn them on or off per actor.

The same statistics also power a new Fediverse Stats block, a yearly snapshot you can drop into any post or page.

On the page, it renders as a clean card styled to match your theme, with colors and fonts picked up automatically from the active block theme, so it feels at home without fiddling.

Underneath, it also generates a shareable image version, a sharepic ready to post to the Fediverse itself. Think of it as your Fediverse year-in-review, without firing up a design tool.

And to make the timing easier, there’s a new seasonal starter pattern that suggests sharing your stats when you create a new post in December or January, the moment when everyone on the timeline is already in reflection mode.

For a long time, the plugin has spoken the server-to-server half of ActivityPub fluently, which is how your posts reach Mastodon, Pixelfed, and the rest. With 8.1.0, the plugin now also exposes an ActivityPub API, an implementation of the Client-to-Server (C2S) half of the protocol.

In plain language: third-party Fediverse apps can now create, edit, and delete posts on your blog directly, the same way they would on a Mastodon account. Alongside the basics, the ActivityPub API also supports Block, Add (pin a post), and Remove (unpin a post) activities. To make app discovery smoother, actor profiles now also expose OAuth server metadata and a registration endpoint, so clients can find their way in without manual setup.

The ActivityPub API is experimental and hidden behind a feature flag. To try it, open the ActivityPub settings page, click Screen Options in the top right, enable Advanced Settings, and save. Under the new Advanced tab, flip on ActivityPub API and you’re off. Once enabled, connected apps can be managed from your profile page.

This is foundational work. Most of what it enables will show up over time, as more apps start treating your WordPress site as something they can post from, not just to.

Starter Packs are one of the easier ways to onboard onto a new Fediverse platform: follow a curated list of people and you land somewhere with a timeline already humming.

8.1.0 adds support for importing Starter Packs in both the Pixelfed and Mastodon formats. If you’re moving to WordPress from another Fediverse platform, or setting up a new blog and want to bootstrap your Following list, point the importer at a Starter Pack and the plugin will take care of the rest.

Photographers, this one’s for you. Image attachments now carry EXIF metadata (camera body, lens, focal length, aperture, shutter speed, ISO) using the Vernissage namespace.

The short version: the information that makes a photo worth reading about no longer gets stripped on the way out. Vernissage and other photo-focused Fediverse platforms can pick up the metadata and display it alongside the image, the way they would for a native post.

• Add rate limiting to app registration to prevent abuse.
• Fix blog actor outbox exposing private activities to unauthenticated visitors.
• Restrict localhost URL allowance to local development environments only.
• Verify that the signing key belongs to the same server as the activity actor.

• Add a “Posts and Replies” tab bar for author archives that filters between posts and replies, similar to Mastodon’s profile view.
• Add a liked collection to actor profiles, showing all posts the actor has liked.
• Add a seasonal starter pattern that suggests sharing Fediverse stats when creating a new post in December and January.
• Add a stats block that displays annual Fediverse statistics as a card on the site and as a shareable image on the Fediverse, with automatic color and font adoption from the site’s theme.
• Add Fediverse statistics dashboard widget with engagement metrics, charts, and monthly/annual email reports.
• Added activitypub_pre_get_by_id filter to allow plugins to register custom virtual actors resolved by ID.
• Add EXIF metadata support for image attachments using Vernissage namespace.
• Add new Fediverse Following Page and Profile Page block patterns.
• Add OAuth server metadata and registration endpoint discovery to actor profiles.
• Add real-time streaming for inbox and outbox updates via Server-Sent Events (SSE).
• Add support for Block, Add (pin post), and Remove (unpin post) activities via Client-to-Server API.
• Add support for check-in activities posted via compatible apps.
• Add support for importing Starter Packs in both the Pixelfed and Mastodon formats.
• Add tags.pub integration to supplement tag timelines with posts from across the Fediverse.
• Support for ActivityPub Client-to-Server (C2S) protocol, allowing apps like federated clients to create, edit, and delete posts on your behalf.

• Block patterns for follow, following, and profile pages are now only suggested when editing pages.
• Fix notification pagination when using Enable Mastodon Apps: use date-constrained queries instead of truncating the shared notification pool, and expose $limit, $before_date, and $after_date as additional filter arguments so third-party handlers can fetch the correct window.
• Improve the pre-publish format suggestion panel with clearer messages and a confirmation after applying a format.
• Podcast episodes now respect the configured object type setting instead of always being sent as “Note”.
• Show reaction action buttons even when a post has no reactions yet.

• ActivityPub endpoints that surface comment, reply, like, share, and remote-reply metadata now honor the parent post’s visibility setting.
• Added validation for SSE access tokens passed via query parameter.
• Fix account migration (Move) not working when moving back to an external account.
• Fix a fatal error during activity delivery when the outbox item has been deleted.
• Fix a fatal error when receiving activities with a non-string language property.
• Fix a fatal array_keys(null) in Comment::get_comment_type_slugs() that could take down any request where a third-party plugin transitioned a custom comment type before add_comment_type() had been called.
• Fix a missing script dependency notice on the admin page in WordPress 6.9.1 and later.
• Fix BuddyPress @mention filter corrupting Fediverse Followers and Following blocks.
• Fix cleanup jobs silently doing nothing on sites where purge retention options were not set.
• Fix comments on remote posts being incorrectly held in moderation.
• Fix double-encoded HTML entities in post titles on the Fediverse Stats dashboard.
• Fixed an issue where quote authorization stamps could reference unrelated posts.
• Fixed double-encoding of special characters in comment author names on updates.
• Fixed emoji shortcode replacement to handle special characters in emoji names correctly.
• Fix fatal error when other plugins hook into the user agent filter expecting two arguments.
• Fix Fediverse Preview showing the standard web view instead of the ActivityPub preview for draft posts.
• Fix OAuth authentication failing for local development clients using localhost subdomains.
• Fix performance regression from reply-exclusion filter by skipping it for queries targeting non-ActivityPub post types.
• Fix Reader feed failing to load with newer WordPress versions.
• Fix remote actor avatars getting stuck on broken URLs when the original image becomes unavailable.
• Fix Site Health check showing an empty error message when the WebFinger endpoint is not reachable.
• Fix the Fediverse profile “Joined” date showing the oldest post date instead of when the site started federating.
• Fix the Fediverse profile showing an inflated post count by excluding incoming comments from the total.
• Fix Update handler using stale local actor data instead of the activity payload.
• Improved HTTP Signature validation for requests with a missing Date header.
• Only allow S256 as PKCE code challenge method for OAuth authorization.
• Prevent third-party plugin UI elements and scripts from appearing in federated content.
• Require signed peer requests for the followers synchronization endpoint per FEP-8fcf.
• Show a styled error page instead of raw technical output when an OAuth application cannot be reached during authorization.
• Strip private recipient fields from all outgoing activities to prevent leaking private audiences.
• Sync ActivityPub blog actor settings via Jetpack.
• Use ap_actor post ID for remote account IDs instead of remapping URI strings.
• Use safe HTTP request for signature retry to prevent requests to private IP ranges.
• Validate emoji updated timestamps before storing them.

Download from WordPress.org or grab it on GitHub.

A huge thank you to everyone who contributed code, testing, bug reports, and ideas to this release.

Update, drop a stats block into your next recap post, and let us know what you think. Which number surprised you most? Which Fediverse app are you most excited to try with your blog?

This release puts speed and control right at your fingertips. Whether you’re jumping between settings, syncing followers, or handling quotes in real time, version 7.6.0 makes managing your Fediverse presence faster and more intuitive than ever.

Say hello to the quickest way to move around your ActivityPub settings.

In preparation for WordPress 6.9, which brings the Command Palette (Cmd/Ctrl + K) to the entire wp-admin, the plugin now adds its own commands, giving you instant, keyboard-driven access to your workflows anywhere in WordPress.

Type “ActivityPub” and you’ll see context-aware commands that adapt to your site setup and user role. Whether you’re managing a blog actor or a user actor, you can open followers and following lists, check blocked actors, jump straight to your settings, or even search and edit extra fields — all without ever leaving the Command Palette.

Every command includes the ActivityPub icon for easy recognition. Just press Cmd + K or Ctrl + K, start typing, and go — it’s the smoothest way yet to pilot your Fediverse setup.

Your follower lists now stay accurate wherever you connect.
With support for Follower Synchronization (FEP-8fcf), the plugin automatically keeps your followers collection in step with other servers — even when things drift out of sync.

If differences appear, background tasks quietly reconcile them, keeping your lists clean and consistent. The result is a smoother, more reliable experience across the entire Fediverse — no manual fixes required.

Quoted posts and follow confirmations now move at the speed of conversation.

A new immediate Accept dispatch system sends responses as soon as they’re created, instead of waiting for the next scheduled queue.

That means faster follow confirmations and quicker quote acknowledgments, making interactions feel more natural across the Fediverse. Behind the scenes, those Accept messages go straight to the right inboxes — including mentioned and replied-to users — while a scheduled backup ensures full compatibility with slower servers.

It’s a smart balance between speed and reliability, helping your posts and follows appear almost instantly.

Want to keep your social graph private? You can now hide your followers and following lists from public view while keeping all relationships intact. Your followers still follow — they’re just hidden when you prefer a little more privacy.

• Add bidirectional transforms between reply and embed blocks for improved user experience.
• Add Command Palette integration for quick navigation to ActivityPub admin pages
• Added a new ap_object post type and taxonomies for storing and managing incoming ActivityPub objects, with updated handlers
• Added a privacy option to hide followers and following lists from profiles while keeping follow relationships intact.
• Added a scheduled task and setting to automatically purge old inbox items, helping maintain site performance and storage control.
• Added fallback to trigger create handling when updates fail for missing posts or comments, ensuring objects are properly created.
• Added immediate dispatch for Accept activities to speed up quoted posts while keeping scheduled processing for compatibility with other instances.
• Added new configuration options to better manage traffic spikes when federating posts, allowing finer control over retry limits, delays, and batch pauses.
• Added support for FEP-8fcf follower synchronization, improving data consistency across servers with new sync headers, digest checks, and reconciliation tasks.
• Add LiteSpeed Cache integration to prevent ActivityPub JSON responses from being cached incorrectly. Includes automatic .htaccess rules and Site Health check to ensure proper configuration.
• Add quote visibility setting for Classic Editor users.
• Add unified attachment processor for handling ActivityPub media imports from both remote URLs and local files, with automatic media block generation and Classic Editor support.
• Integrate Federated Reply block with WP.com Reader’s post share functionality, allowing users to reply to ActivityPub posts directly from the Reader.

• Added support for FEP-3b86 Activity Intents, extending WebFinger and REST interactions with new Create and Follow intent links.
• Added support for the latest NodeInfo (FEP-0151), with improved federation details, staff info, and software metadata for better ActivityPub compliance.
• Extended inbox support for undoing Like, Create, and Announce activities, with refactored undo logic and improved activity persistence.
• Improved Classic Editor integration by adding better media handling and full test coverage for attachments, permissions, and metadata.
• Improved delivery of public and follower activities by expanding local recipient handling to include all ActivityPub-capable users and follower collections.
• Improved inbox performance by batching and deduplicating activities, reducing redundant processing and improving handling during high activity periods.
• Improved REST API responses with smarter context handling.
• Improved REST collection pagination by using explicit total item counts for more accurate results.
• Moved default visibility handling from the server to the editor UI, ensuring consistent and flexible ActivityPub visibility settings across both block and classic editors.
• Prevented self-announcing by ignoring announces from the blog actor, while still processing announces from user and external actors.
• Refactored activity handling to support multiple recipients per activity, allowing posts and interactions to be linked to several local users at once.
• Refactored avatar handling into a new system that stores and manages avatars per remote actor, improving reliability and preparing for future caching support.
• Refactored the inbox system to use a shared inbox, storing activities once with multiple recipients for improved efficiency and reduced duplication.
• Reorganize integration loader and move Stream integration into dedicated folder structure.
• Reply posts: do not display post title before @mentions in posts that are replies to somebody else
• Simplified configuration by always enabling the shared inbox and removing its separate setting, UI field, and related logic.
• Simplified inbox storage settings, allowing certain activities (like deletes) to be skipped to reduce unnecessary database use.
• Simplify follow() API return types to int|WP_Error for better predictability.
• Updated inbox handling to support multiple users receiving the same activity and improve overall data consistency.
• Updated mailer hooks to send notifications only when activities are successfully handled, preventing emails for failed events.
• Update plugin short description to be more user-friendly.

• Reply block now properly validates ActivityPub URLs before setting inReplyTo field
• Added a safeguard to ensure the plugin works correctly even when no post types are selected.
• Added a safety check to prevent errors when resolving comment author hostnames without a valid IP address.
• Fixed activity processing to handle QuoteRequest and other edge cases more reliably.
• Fixed an issue with post content templates to ensure the correct fallback is always applied.
• Fixed fatal error when transformer Factory receives WP_Error objects.
• Fixed HTML entity encoding in extra field names when displayed on ActivityPub platforms
• Fixed typo in example, improve quoting description.
• Fix Following table error message to display user input instead of empty string when webfinger lookup fails.
• Fix infinite recursion when storing remote actors with mentions in their bios
• Fix local inbox delivery to use internal REST API instead of HTTP, enabling local follows and proper boost counting.
• Fix logic errors in Move handler: remove redundant assignment and fix variable name collision.
• Fix public key retrieval for GoToSocial profiles with path-based key URLs.
• Improved actor resolution by prioritizing blog actor detection before remote actor checks and refining home page URL handling.
• Improved handling of empty fields for better compatibility with Pixelfed and more consistent fallback behavior across actor names, URLs, and related data.
• Improved hashtag encoding for consistent formatting.
• Improved Jetpack integration by initializing it during the WordPress startup process.
• Refactored Mastodon import handling to use consistent array-based data, improving reliability and compatibility across all import scenarios.

• WordPress.org: activitypub.7.6.0.zip
• GitHub: tag/7.6.0
• WordPress.org: activitypub.7.6.1.zip
• GitHub: tag/7.6.1

Big thanks to everyone who contributed code, feedback, and testing to make this release possible. You keep ActivityPub evolving with every version.

Version 7.6.0 is now live — update today and enjoy lightning-fast navigation, smarter synchronization, and smoother federation! ❤️

Running a community in the Fediverse means balancing openness with safety. Every year, @iftas@mastodon.iftas.org takes the pulse of administrators, moderators, and community managers with their Annual Needs Assessment. This survey helps identify what’s working, where support is needed, and which tools can make a difference for those keeping decentralized spaces safe.

The 2025 survey is now open

Take part in the IFTAS Needs Assessment (5–10 minutes).

(If you haven’t seen them before, you can also take a look at last year’s report)

Last year’s responses represented moderators of over 4.3 million accounts across ActivityPub platforms. With WordPress now the largest group of federating instances, it’s especially important for our community of hosts, site admins, and moderators to be heard.

We recently introduced a major update to the ActivityPub plugin for WordPress: personalized and site-wide moderation tools.

• Site administrators can now set domain, keyword, and actor-level blocks that protect the entire site.
• Individual users can fine-tune their own experience with personal blocks, managed directly from their profiles.
• Content is checked against both global and personal rules—so moderation works at every level.

These improvements directly address needs raised in previous IFTAS surveys, making moderation more discoverable, flexible, and effective for WordPress communities in the Fediverse.

IFTAS uses the Needs Assessment to guide tools, policies, and advocacy that reflect the real-world challenges of moderators—especially those in under-resourced communities. The more representative the responses, the stronger the outcomes for everyone.

If you’re running a federating WordPress site, please consider:

1. Filling out the survey yourself.
2. Sharing it with other admins, moderators, and community organizers.
3. Reminding folks that it’s anonymous, quick, and impactful.

Together, we can keep building a safer, healthier Fediverse—one that reflects the needs of its communities.

Radical Speed Month is over, and today we’re releasing the work to the public. For four weeks, we built out the WordPress.com Reader so it can read and write across three networks (Bluesky, Mastodon, and the Fediverse), all from one place. The new Social section in the Reader’s sidebar is now live for everyone.

A full write-up will follow next week on the WordPress.com blog, covering the full experience across all three networks.

We’ve had a few excursions on this blog lately (Radical Speed Month, ATmosphere 1.0.0), so we want to bring the focus back to ActivityPub and the plugin.

The plugin’s ActivityPub API now powers its first real production client: the WordPress.com Reader. As a WordPress.com user, you can now read, follow, and post across the Fediverse through your WordPress blog, with every interaction tied to your blog’s own ActivityPub identity, and it all sits next to the rest of your Reader.

At the moment, this works for WordPress.com and Jetpack-connected sites (Jetpack may take a few more days to roll out fully), with self-hosted blogs coming next. Beyond that, the goal is to support any site that speaks the API. The Reader is the first client we’ve built on it, and what we learn here will also feed into the broader WordPress reading experience.

If your WordPress.com site has joined the Fediverse, it shows up in the Reader’s new Social section automatically, next to any Bluesky or Mastodon accounts you’ve connected.

Open it from the sidebar and you’ll land on a dedicated view of your blog’s Fediverse activity. The help center has the full walk-through. Here’s what you can do there:

• Read posts from accounts your site follows.
• See your followers and the accounts your site follows back.
• Follow new Fediverse accounts.
• Publish short posts. Past the character limit, the composer offers to move your draft to the block editor.

• Get notifications when someone follows you, mentions you, replies to a post, likes one, or boosts one.
• Tap a @mention to open that person’s profile inside the Reader.

All of this goes through the ActivityPub API on the plugin side. The plugin handles the rest: publishing, signing, federating, receiving. The same machinery your site has always used.

A few things still need work on the plugin or spec side before they land here:

• Liking, boosting, and replying to other people’s posts. Those land slice by slice over the next releases.
• Media in posts you publish from the Reader. Text only for now. The block editor stays the place for images.
• Connecting from a self-hosted WordPress site. For now, the Reader only reaches WordPress.com and Jetpack-connected sites. Self-hosted is next.

The plugin’s ActivityPub API has been experimental since 8.1.0. The Reader is the first product to drive it with real users, and that changes two things.

First, anyone building (or thinking about building) an ActivityPub client now has a real, working server to develop against. The plugin handles publishing, signing, and federation; a third-party client only needs to worry about its own surface. That means more clients become possible, and the people running the plugin get more ways to use their site, beyond the Reader.

Second, real traffic finds the kind of edge cases test cases never do. Authentication quirks, payload shapes, error paths, the things that only show up at scale. Every bug that comes out of real use is one we can fix, and the plugin becomes more reliable for everyone who runs it.

The ActivityPub API in the plugin is still experimental, and the wider spec is still being worked on. The W3C Social Web Community Group and its ActivityPub API task force are addressing the gaps real clients run into. We follow that work and join in where we can help.

A few topics worth watching:

• Server-local metadata on foreign objects (activitypub-api#60): how a server can pass on what it knows locally about a post (replies, likes, shares, plus a small “did this caller interact” note) when a client fetches it.
• Announce side-effects from the client side (activitypub/#512): what the outbox should do to the local shares collection when a client posts an Announce.
• The baseline profile (SWICG activitypub-api): what a server should tell clients about itself, and what a client should be able to count on.

If any of these are interesting to you, the discussions are open. Your feedback is welcome.

If your WordPress.com site is Fediverse-enabled, open the Reader and find your site under Social. Try following someone, or publishing a short note. The full walk-through is in the help center.

If you run the plugin on a self-hosted site, the same ActivityPub API is available to you, just off by default while it’s experimental. You can turn it on under Settings → ActivityPub, in the Advanced tab. If the Advanced tab isn’t showing, enable it from Screen Options at the top-right of the page first. The Reader doesn’t reach self-hosted sites yet, but once the API is on, any client that speaks it can already talk to your site.

If something doesn’t work, leave a comment, open an issue on the plugin’s GitHub repository, or reply on the Fediverse. What would you like to see next?