Posts by activitypub.blog@activitypub.blog
 (DIR) Post #B4tUtrM9xzjXKfdQ48 by activitypub.blog@activitypub.blog
       0 likes, 1 repeats
       
       One of the best things about the Fediverse is that conversations happen everywhere, across Mastodon, WordPress, Pixelfed, and dozens of other platforms. One of the trickiest things about the Fediverse is finding those conversations in the first place.Hashtags have always been the Fediverse’s answer to discovery. But because the network is decentralized, the posts you see for any given hashtag depend on which servers yours already knows about. If nobody on your server follows someone who posted about #WordPressFederation, you’ll never see that post, even though it’s public and out there.tags.pub changes that.What Is tags.pub?tags.pub is a global hashtag server built by the Social Web Foundation, a nonprofit dedicated to growing the open social web, and an organization Automattic is proud to partner with.The idea is simple: tags.pub collects publicly posted content from across the Fediverse and redistributes it based on hashtags. When you follow a hashtag account like @photography@tags.pub, you’ll see posts tagged #photography from servers your instance might never have heard of. It fills in the gaps that decentralization naturally creates.The project is open source (AGPL-3.0), privacy-conscious, it doesn’t store post content, images, or media, and respects user controls like #NoTagsPub and #NoBots opt-outs.How It Works on WordPress.comIf you’re running a WordPress.com site with the ActivityPub plugin, there’s nothing to configure. tags.pub already works out of the box. Your public posts and their hashtags are discoverable across the Fediverse through tags.pub, and you can follow hashtag accounts from your Following page.Connecting a Self-Hosted WordPress SiteFor self-hosted WordPress sites, head to Settings → ActivityPub → Settings and scroll to the Relay section. Add one of these URLs:Inbox: https://tags.pub/user/_____relay_____/inboxShared Inbox: https://tags.pub/shared/inboxThis creates a one-way connection where your server sends public posts to tags.pub for hashtag distribution, and your posts become part of the global hashtag network.Following HashtagsOnce connected, you can also follow specific hashtags by searching for them as accounts. For example, to follow #WordPress posts from across the entire Fediverse, follow:@wordpress@tags.pubAny publicly tagged post that reaches tags.pub will be boosted by that account into your timeline. When posts are edited or deleted, tags.pub updates accordingly.Privacy and Controltags.pub is designed with user agency in mind:Opt out anytime by adding #NoTagsPub or #NoBots to your bio, your posts won’t be boosted.Block the domain entirely if you prefer not to interact with the service at all.No content storage, tags.pub doesn’t archive your posts, images, or media. It only maintains boost records.Respects blocks, if someone blocks tags.pub, their content stays out.A Step Toward Better DiscoveryDiscoverability is one of the areas we’ve identified on our 2026 roadmap as a key challenge, and services like tags.pub are exactly the kind of infrastructure that helps solve it. By connecting WordPress sites to a global hashtag network, your posts can reach people who care about the same topics, even if they’ve never heard of your blog before.If you’re already using ActivityPub for WordPress, connecting to tags.pub takes less than a minute. Give it a try and let us know how it works for you. Have you noticed more engagement from the wider Fediverse? We’d love to hear about your experience.
       
 (DIR) Post #B5zRZSn4VMkKEm52n2 by activitypub.blog@activitypub.blog
       0 likes, 1 repeats
       
       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 thesisThe 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.What’s already landedReader as a sync backendAny 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.Bluesky timelines, threads, and profilesThe 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, the same shapeMastodon 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.How this connects to the pluginIf 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.What’s still plannedA 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 note on speedA 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.What this means for youIf 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.Tell us what you’d like to seeWe’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.
       
 (DIR) Post #B6UX5pDPBk4CixPEYa by activitypub.blog@activitypub.blog
       0 likes, 1 repeats
       
       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.What ATmosphere isWhen 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.How this differs from a cross-posterThe 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.Why a third-party PDS, for nowThere’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 😉Your domain, your handleOne 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.Long posts, done rightThe 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.Two-way conversationsWhen 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.A few more things worth knowingBackfill. 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.Get ItDownload from WordPress.org or grab the source on GitHub.A dedicated blog?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) 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?
       
 (DIR) Post #B6YfpOZW9kvdg4pT3g by activitypub.blog@activitypub.blog
       0 likes, 1 repeats
       
       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.Your WordPress site, inside the ReaderIf 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.What’s not in this release yetA 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.What this means for the pluginThe 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 spec evolves, and we followThe 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.Try itIf 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?
       
 (DIR) Post #B7Q3vgMX8B9sSRicIy by activitypub.blog@activitypub.blog
       0 likes, 1 repeats
       
       Major versions are the right moment to fix things properly instead of patching around them. In ActivityPub plugin 9.0.0, unpublishing a federated post sends a real Delete instead of a placeholder text, and federation can be tuned down so it doesn’t overwhelm smaller servers. The ActivityPub API moves closer to the W3C standard, and your blog can now be featured in Starter Kits, if you allow it.Starter Kits, With Your ConsentStarter Kits are curated lists of accounts, bundled so that others can discover and follow them in one go. You may know the idea as Starter Packs from Bluesky, and Mastodon is rolling out its own version called Collections with version 4.6. The name varies, the idea is the same: someone who knows a topic well puts together a list of accounts worth following, and shares it.For blogs, discovery is the hard part of the Fediverse. A blog doesn’t post twenty times a day, so it rarely surfaces in busy timelines on its own. Being part of a Starter Kit changes that: when someone shares a “great photography blogs” kit, every person who opens it sees your blog, and following is one tap away.One piece was missing, though: other people couldn’t add your WordPress blog to their lists, because your site never told their server who is allowed to do that. ActivityPub 9.0.0 fixes this with the new Default Starter Kit policy setting: Anyone, Followers only, or Just me. The default is “Just me”, so nothing changes unless you say so. If you want the reach, set it to “Anyone” under Settings → ActivityPub → Activities. Under the hood, this announces a canFeature policy on your profile, based on a new Fediverse Enhancement Proposal (FEP-7aa9) that is not published yet; we’ll link it here once it is.The Mastodon team explains the thinking behind Collections in their design post, and Fedi.Tips has a guide to Mastodon’s Lists feature, the private cousin of Collections. And since ActivityPub 8.1.0 you can import Starter Kits into WordPress under Tools → Import, so it works in both directions.Blurred Previews for Your PhotosPhotos are heavy. While they load, most Fediverse apps show an empty gray box.The plugin now generates a BlurHash for every image: a tiny, blurred color preview that other Fediverse apps can show while the real photo loads. Your followers see a soft impression of the picture instead of an empty rectangle. The BlurHash website has a nice interactive demo.The plugin uses the same blurhash property that Mastodon documents as part of its ActivityPub extensions, so your previews work wherever Mastodon’s do. Everything happens automatically in the background; there’s nothing to configure.From Placeholder to DeleteUntil now, when you moved a federated post back to draft or made it private, the plugin sent an Update with a placeholder text: “(This post is being modified)”. Your followers kept a copy that claimed the post was being edited, even if it never came back. That was a workaround, and a bad one: it misrepresented your content and left stale placeholders sitting in timelines across the Fediverse.ActivityPub 9.0.0 replaces the workaround with the behavior the Fediverse expects. When a federated post moves to draft, pending, private, trash, or gets a password, the plugin now sends a Delete to your followers, so their servers remove their copies. Your site keeps a Tombstone in place of the post, as described in FEP-4f05, so it can announce the post again if you re-publish it.Be aware: even unpublishing a post only temporarily might delete it forever on other servers. When you take a post down on purpose, that’s what you want. But if you plan to come back, know that whether the post comes back with you depends on the receiving server, and the boosts, favorites, and replies on the old copies are gone either way. Discourse and NodeBB restore posts like this; Mastodon currently does not, though there’s an open issue we hope to see land soon. For now, treat unpublishing as deleting, even if you plan to publish again.That’s why the editor now warns you before you make a federated post a draft, private, or password-protected. The dialog tells you that followers’ copies will be removed, so you know what will happen before you save.Federation That Doesn’t Overwhelm Your ServerFederation is real work. When you publish a post, the plugin sends it to every follower’s server, and each delivery is a signed HTTP request processed in the background. On a well-provisioned server, no problem. On shared hosting with a few thousand followers, that burst of background work can slow your whole site down, right at the moment your new post brings visitors in.The new Distribution Mode setting exists so the plugin stays a good guest on the server it runs on. It comes with three presets:Default: the current behavior, as fast as possible (100 deliveries per batch, 15 seconds pause).Balanced: a moderate pace (50 per batch, 30 seconds pause).Eco Mode: gentle on server resources, made for shared hosting (20 per batch, 30 seconds pause).Nothing changes unless you need it to: Default behaves exactly like before. But if your site gets sluggish after publishing, switch to Balanced or Eco Mode under the Advanced tab of the ActivityPub settings. Your followers get the post a few minutes later, and your server keeps breathing. A Custom mode with your own batch size and pause is there for fine-tuning.The Advanced tab is hidden by default. To enable it, open the ActivityPub settings page, click Screen Options in the top right corner, check Advanced Settings, and save.Hosting providers can pin a preset across all their sites with the ACTIVITYPUB_DISTRIBUTION_MODE constant, so a whole fleet of sites stays well-behaved without anyone touching a setting.Speaking Standard ActivityPubThe ActivityPub API (the plugin’s Client-to-Server implementation) keeps converging on what the W3C SWICG is standardizing. Clients can now request the canonical SWICG scope names like activitypub:read:all and activitypub:write:all, and the OAuth discovery metadata advertises them. Token responses include activitypub_actor_id, following the SWICG ActivityPub API Basic Profile, and rate-limit responses now carry a Retry-After header so clients know how long to wait.None of this changes anything for existing apps. It just means new apps can connect to your site by following the standard, not our documentation.Since this is a major version, there’s one heads-up for developers: we removed functions, methods, and the Follower class that were deprecated in versions 7.0 through 7.4. Everything removed has had a documented replacement for over a year, but if your plugin or theme builds on ActivityPub internals, check the changelog before updating.A Good Reason to Update SoonBeyond the features, 9.0.0 includes a series of security hardening fixes that keep private data private and tighten how the plugin verifies who is allowed to change what. None of them need anything from you beyond updating, which is exactly why you should update soon. The details are in the changelog below.ChangelogAddedAdd a Distribution Mode setting to control how quickly posts are delivered to followers.Add an opt-in setting to consent to inclusion in Starter Kits (also called Starter Packs or Featured Collections). Off by default. Find it under Settings, ActivityPub, Activities.C2S clients can now request canonical SWICG ActivityPub API scope names such as activitypub:read:all and activitypub:write:all, and the OAuth discovery metadata advertises them.C2S token responses now include activitypub_actor_id so clients following the SWICG ActivityPub API Basic Profile can discover the authenticated actor.Generate a blurred color preview (blurhash) for images so other fediverse apps can show a placeholder while your photos load.Quote notification emails now include a link to the post that quoted you, so you can review and respond more quickly.Warn in the editor before making a post that’s already shared on the Fediverse a draft, private, or password-protected, since followers’ copies will be removed.ChangedAdd the blurhash term to the outbound JSON-LD @context so attachments that include a blurhash property are strictly correct JSON-LD, matching Mastodon’s own context shape.Federated posts moved to draft, pending, private, trash, or password-protected now send a Delete to followers (previously sent a placeholder “editing” Update or were silent).OAuth rate-limit responses now include a Retry-After header so clients know how long to wait before retrying.Updated a build dependency to a clean release now that a fixed version is available.RemovedRemoved functions, methods, and the Follower class that were deprecated in versions 7.0 through 7.4.FixedFix a fatal error when receiving a new follower while the Stream plugin is active.Fix a follow request being marked as accepted when the confirmation came from a different account than the one being followed.Fix the Fediverse settings appearing twice and visibility changes not saving in the block editor when the Classic Editor plugin is also active.Fix the introduction video failing to load on the Getting Started help screen.Follower synchronization with Mastodon no longer fails, signed requests with query strings now verify correctly.Harden the Blurhash encoder: skip decompression-bomb images before decoding, flatten transparency onto white so transparent logos no longer produce near-black placeholders, and defer the cron encode until attachment metadata is saved.Images and videos placed in a Media & Text block are now included when a post is shared to the Fediverse.Requests from other platforms to feature your posts are now handled correctly instead of being ignored.RSS and Atom feeds now show a simple @username mention in place of the reply block’s full embed card, which only renders properly when the plugin’s frontend CSS is loaded.Stop a deprecation notice from appearing in the error log when the NodeInfo plugin is also active.SecurityEnforce the signing-key host check on incoming federated activities regardless of how the key identifier is formatted.Fix the real-time activity stream so it only returns the requesting user’s own activities.Harden the Site Health connectivity check so it cannot be used to reach unsafe network addresses.Only share comment replies in the Fediverse when the post they belong to is itself federated, so replies on private or non-federated posts stay private.Prevent a remote server from discovering which of your followers belong to a third-party server it does not control.Prevent logged-in users from viewing another user’s private outbox activities.Prevent remote servers from modifying or deleting federated profiles, posts, and interactions they do not own.Rate-limit the remote-follow lookup to prevent it from being abused to trigger outbound requests.Stop the OAuth token introspection endpoint from revealing another user’s token details to logged-in users.Stop the quote-authorization stamp from exposing a post’s other metadata.Get ItDownload 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. Special thanks to .Update, and let us know what you think: will you open your blog up for Starter Kits? And does the new delete behavior match what you expected your site to do all along?
       
 (DIR) Post #BA0CLySB0pm1qi7yBU by activitypub.blog@activitypub.blog
       0 likes, 1 repeats
       
       It has been almost three months since 9.0.0, and eight releases: 9.0.1, 9.0.2, 9.1.0, 9.2.0, 9.2.1, 9.2.2, 9.3.0, and now 9.3.1. Together they added seven new things, closed ten security issues, and fixed close to fifty bugs, which is a very different balance than usual.This post covers the new things first, and then explains where the rest of the summer went.Modern Signatures, On by DefaultEvery message your site sends to the Fediverse carries a signature, the digital equivalent of a wax seal on an envelope. In July 2025 we wrote about the move from the old draft format to RFC 9421, the official standard. Back then, sending with the new format was a setting for early adopters, and we promised to turn it on for everyone once the rest of the Fediverse was ready.With 9.3.0 it is on by default. Your site now signs outgoing requests with RFC 9421, and falls back to the old format when the server on the other side does not understand it yet. For almost everyone this changes nothing you can see. Your posts keep arriving, your follows keep working.A small number of servers advertise support for the new format but handle it differently in practice. If your posts suddenly stop arriving on one particular server after this update, you can switch back. Open the ActivityPub settings, click Screen Options in the top right, enable Advanced Settings, and turn off the modern signature format in the Advanced tab. Please let us know in the support forum which server it was, so we can look into it.Your Podcast Travels With Its AudioIf you publish podcast episodes with Jetpack, your episodes now federate as episodes. The audio file and the cover art travel with the post, so your followers get a playable player in their Fediverse app instead of a link they have to click through.Version 9.1.0 did the same for Podlove Podcast Publisher, where the episode summary now goes out with the post rather than being dropped.A Quieter InboxLikes, reposts, and quotes are lovely until there are two hundred of them and your email inbox has two hundred entries. Until now, switching those off meant switching off notifications for real comments and replies too.9.3.0 separates them. There is a new notification setting that turns off emails about likes, reposts, and quotes, while comments and replies from the Fediverse keep reaching you. Reactions still show up on your post, you just stop hearing about each one individually.Smaller Things You Might NoticeFediverse and ActivityPub logos in the editor. On WordPress 7.1 and newer, both logos are part of the block editor’s icon library, so you can use them in a Social Icons block or anywhere else an icon fits.The follow, reply, and reaction dialogs speak up. Screen readers now announce errors in those dialogs instead of leaving people guessing why nothing happened.Scheduled posts show the right preview. Since 9.1.0, a scheduled post shows the Fediverse Preview, so you can see what your followers will get before it goes out.Avatars that actually update. The scheduled refresh of remote profiles was not refreshing anything. Commenters kept the avatar and bio they had when they first showed up. Fixed in 9.1.0.Two new FAQ guides, added in 9.0.1, for the two questions we get most often: follow requests stuck on “pending”, and comments from the Fediverse not appearing on your posts.For People Building on the Plugin9.1.0 added an actor autocomplete endpoint, so a Fediverse app connected to your site can offer typeahead search when you are mentioning someone. There is also a new filter for sites that need to federate inside a private or internal network, which mostly matters for intranets and staging setups.In 9.3.0, apps connected through the ActivityPub API now use the standard permission names from the specification, and fetching remote content through your site counts as reading rather than posting. Apps also see the real error when a post is missing, instead of a generic failure that told them nothing.Where the Summer WentSeven new things in three months is not much. Here is the reason.Since June we have had a steady stream of security reports. Ten of them became entries in the changelogs of 9.1.0 and 9.3.0, and a few more landed quietly as fixes. Every report has to be read, reproduced, judged, fixed, tested, and shipped, and the fix has to be written so it does not break the sites that already work. For a team our size that is most of a week each time, sometimes more.This is not a complaint, and a real thank you to everyone who sent a report and then waited while we worked through the queue. Nearly all of the reports were real, and every one of them made the plugin safer for the people running it. This is responsible disclosure working the way it should. It just means the roadmap moves slower than it looks on paper, and features that were planned for July are still open.We are not alone in this. WordPress core is seeing the same wave, and for the same reason: AI models have become good enough at reading code that finding a plausible vulnerability is now cheap. The security team wrote about it in The Core Security Initiative, and the project started Protect The Shire to review the code in the plugin and theme directories at a scale that was not possible before. The same tools that raise the number of reports also help everyone work through them. On balance, we think this is good for the ecosystem, even on the weeks where it does not feel like it.In general terms, the security work in these releases covers four areas:Content from other servers is cleaned before it is stored, and again before it is displayed, so what another server sends cannot influence how your site behaves.Data that belongs to you stays yours. Your followers, the profiles your site has cached, and your reader posts are not readable by logged-out visitors, and the setting that hides your follower list is respected everywhere.Activities are checked more strictly against the account they claim to come from, so a server cannot act on behalf of someone else.Apps you connect can only do what you allowed them to do, and nothing wider.We are keeping this vague on purpose. The details are in the reports, and we would rather not hand a recipe to anyone whose site has not updated yet. If you run the plugin, please update.What the Fixes CoverThe fifty or so fixes across these releases are not one story, but they fall into a few groups:Finding each other. Profiles and posts were not always found when an address contained unusual characters, or was written with different capitalisation, or when the other server answered in an unexpected shape. Several fixes make lookups work in all of those cases.Reactions arriving once. Likes and boosts could be recorded as duplicate comments, or come back after you marked them as spam. A deletion on Mastodon did not always remove the matching comment on your site. Both are fixed.Caching. ActivityPub responses were sometimes stored by page caches meant for regular web pages. Since 9.2.0, those responses are served only to clients that ask for ActivityPub data and nothing else, which keeps them out of caches like LiteSpeed and Surge. Support for the WP REST Cache plugin was removed as part of this.Publishing edge cases. Posts scheduled for a future date were removed from the Fediverse when edited. Hidden page elements, like the text inside a closed dialog, ended up in the content sent to your followers. Backslashes vanished from imported titles. Small things, annoying every time.Living with other plugins. Fixes for sites running Polylang, Jetpack, Surge, and the Mastodon importer, which was creating duplicate posts when an archive was imported twice.Admin screens and the editor. Styles that failed to load on the Fediverse screens and in the Followers and Following blocks, an editor warning about unsaved changes that appeared right after saving, and a handful of errors that filled up log files without breaking anything visible.The full, item-by-item changelog for every release is in the plugin’s changelog if you want to read it in detail.Get ItDownload from WordPress.org or grab it on GitHub. If your site updates automatically, you already have it.Thanks to everyone who filed a bug report with steps we could follow. Those are the ones that get fixed fastest.Now that signatures are modern by default: does anything still deliver differently for you? And what would you like to see us build once the queue is shorter?