Salta al contenuto principale


7.0.0 – I will follow you!


Just when you thought things were settling down… boom 💥 — the ActivityPub plugin gets another big upgrade. Say hello to version 7.0.0, a release packed with new features, polish, and under-the-hood improvements to help your WordPress site federate smoothe

Just when you thought things were settling down… boom 💥 — the ActivityPub plugin gets another big upgrade. Say hello to version 7.0.0, a release packed with new features, polish, and under-the-hood improvements to help your WordPress site federate smoother, smarter, and more securely than ever.

Let’s dive into what’s new.

Following the Fediverse


We’ve added the initial building blocks for Following support — both sending and managing follow requests for remote actors. It’s not in the UI just yet (we’re rolling it out carefully), but that’s not far away. A big step toward richer, two-way federation.
Wapuu that "follows" a Mastodon, Pixelfed and Ghost mascot.
We’ll work with developers of third-party plugins — including those behind Friends and Event Bridge — to migrate their custom follow implementations to this new core feature. This collaboration helps ensure a consistent, reliable follow experience across the ecosystem.

This foundational support for following is also the first step toward a full-featured reader experience right inside WordPress — something we’re excited to keep building toward.

Refined Signature


This release brings support for RFC-9421-style HTTP signatures, both incoming and (optionally) outgoing. That’s a mouthful, but it basically means supporting the latest standard in how we verify and send activities — including a fallback to good old Draft Cavage when needed.

Check out the blog post to learn more: HTTP Signature Upgrades Coming Soon

Full Changelog

Added


  • Added basic support for handling remote rejections of follow requests.
  • Added basic support for RFC-9421 style signatures for incoming activities.
  • Added initial Following support for Actors, hidden for now until plugins add support.
  • Added missing “Advanced Settings” details to Site Health debug information.
  • Added option to auto-approve reactions like likes and reposts.
  • Added support for namespaced attributes and the dcterms:subject field (FEP-b2b8), as a first step toward phasing out summary-based content warnings.
  • Added support for the WP Rest Cache plugin to help with caching REST API responses.
  • Documented support for FEP-844e.
  • Optional support for RFC-9421 style signatures for outgoing activities, including retry with Draft-Cavage-style signature.
  • Reactions block now supports customizing colors, borders, box-shadows, and typography.
  • Support for sending follow requests to remote actors is now in place, including outbox delivery and status updates—UI integration will follow later.


Changed


  • Comment feeds now show only comments by default, with a new type filter (e.g., like, all) to customize which reactions appear.
  • Consistent naming of Blog user in Block settings.
  • hs2019 signatures for incoming REST API requests now have their algorithm determined based on their public key.
  • Likes, comments, and reposts from the Fediverse now require either a name or preferredUsername to be set when the Discussion option require_name_email is set to true. It falls back to “Anonymous”, if not.
  • Management of public/private keys for Actors now lives in the Actors collection, in preparation for Signature improvements down the line.
  • Notification emails for new reactions received from the Fediverse now link to the moderation page instead of the edit page, preventing errors and making comment management smoother.
  • Plugins now have full control over which Settings tabs are shown in Settings > Activitypub.
  • Reworked follower structure to simplify handling and enable reuse for following mechanism.
  • Screen options in the Activitypub settings page are now filterable.
  • Setting the blog identifier to empty will no longer trigger an error message about it being the same as an existing user name.
  • Step completion tracking in the Welcome tab now even works when the number of steps gets reduced.
  • The image attachment setting is no longer saved to the database if it matches the default value.
  • The welcome page now links to the correct profile when Blog Only mode was selected in the profile mode step.
  • Unified retrieval of comment avatars and re-used core filters to give access to third-part plugins.


Fixed


  • Allow interaction redirect URLs that contain an ampersand.
  • Comments received from the Fediverse no longer show an Edit link in the comment list, despite not being editable.
  • Fixed an issue where links to remote likes and boosts could open raw JSON instead of a proper page.
  • Fixed a potential error when getting an Activitypub ID based on a user ID.
  • HTTP signatures using the hs2019 algorithm now get accepted without error.
  • Improved compatibility with older follower data.
  • Inbox requests that are missing an algorithm parameter in their signature no longer create a PHP warning.
  • Interaction attempts that pass a webfinger ID instead of a URL will work again.
  • Names containing HTML entities now get displayed correctly in the Reactions block’s list of users.
  • Prevent storage of empty or default post meta values.
  • The amount of avatars shown in the Reactions block no longer depends on the amount of likes, but is comment type agnostic.
  • The command-line interface extension, accidentally removed in a recent cleanup, has been restored.
  • The image attachment setting now correctly respects a value of 0, instead of falling back to the default.
  • The Welcome screen now loads with proper styling when shown as a fallback.
  • Using categories as hashtags has been removed to prevent conflicts with tags of the same name.
  • When verifying signatures on incoming requests, the digest header now gets checked as expected.


Downloads



Thank you!


Huge thanks to everyone who contributed code, feedback, tests, or moral support. This community makes the fediverse feel a little more federated with every release. ❤️

Update now, test things out, and let us know how 7.0.0 works for you!



HTTP Signature Upgrades Coming Soon


Ever wonder how your site proves it’s really you talking to the rest of the Fediverse? It’s not magic—it’s HTTP signatures, the digital equivalent of a secret handshake. With our next release, we’re making that handshake a lot more universal (and a little less awkward).

Why HTTP Signatures Matter


When you interact with the Fediverse, you want to know that the messages you send and receive are genuine. HTTP signatures are the technology that makes this possible. Every time your site sends a message, it includes a digital signature—like sealing an envelope with your personal stamp. This signature proves that your content really came from your account and that no one has tampered with it along the way. As a result, you can trust that your interactions across the network are authentic.
A Wapuu dressed as a detective holds a sealed envelope marked with an RFC 9421 checkmark, symbolizing secure and verified communication, with a key floating nearby against a starry background.

A Bit of Background: draft-cavage and RFC 9421


If you’ve heard about HTTP signatures, you might have come across terms like “draft-cavage” and “RFC 9421.” These are just different versions of the rules for how those digital signatures are created and checked.

For a long time, most of the Fediverse has used what’s called the draft-cavage-12 specification. Think of this as a set of instructions that people agreed to try out, but that hadn’t been officially finalized. It worked well enough to let sites talk to each other securely, but because it was just a draft, there were sometimes small differences in how different software used it.

Recently, the community agreed on a final, official version of these rules, called RFC 9421. This is now the standard way to create and verify HTTP signatures. This makes it easier for sites and servers to understand each other and work together, since everyone is following the same process.

Incoming Support for the New Standard, Out of the Box


With this update, the plugin will support incoming HTTP signatures that use the new standard right away. There’s nothing extra you need to do. This means that when other servers use the new, official approach for signatures, your site will recognize and accept them. By making support for the new standard easy and automatic, the plugin helps move the Fediverse forward, encouraging more sites to adopt this approach and making connections across the network more reliable.

Outgoing Requests and the Double Knock Approach


There’s a new setting for outgoing requests, but for most people, there’s no need to touch it. This option is really for the folks who like to be on the cutting edge and want to start using the new standard for outgoing messages right away. If that sounds like you, here’s how to find it: head to the ActivityPub settings in your dashboard, open “Screen Options” at the top right, and enable “Advanced Settings.” Then, click on the Advanced Settings tab and turn on “Use modern signature format for Fediverse communications.”

But don’t feel any pressure—leaving this setting off is perfectly fine. The plugin already handles incoming messages with the new standard out of the box, and we’ll automatically enable outgoing support for everyone once the wider Fediverse is ready. For now, this is just an option for early adopters.

If you do turn it on, the plugin uses what we call the “double knock” approach. It’ll try the new standard first, and if the other server isn’t ready for it, it’ll automatically fall back to the older method. So, you can experiment without worrying about breaking communication with anyone.

Improved Verification for Existing Signatures


The plugin also brings improvements to how it handles signatures that use the older method, especially those using the hs2019 algorithm. Now, when a signed message arrives, the plugin fetches the sender’s public key and uses it to determine the correct way to verify the signature, following the specification more closely. This means more reliable verification and fewer errors, making your experience smoother and more predictable.

Looking Forward


With this update, the plugin helps move the Fediverse toward a shared standard for signing and verifying messages. By supporting both the new standard and the older method, you’re making it easier for everyone to communicate using the same agreed-upon approach. There’s no change in security, but you’re part of making the network more consistent and helping the community take the next step forward.

We hope this explanation helps clarify these technical changes. If you have any questions about HTTP signatures or how our plugin interacts with the Fediverse, please don’t hesitate to reach out in the comments below.


in reply to ActivityPub for WordPress

A reasonable text should go here, not several hundred characters

A lot of us fediverse users would appreciate it if you didn't overload the CW/subject field with almost 500 characters of automatically truncated content from the beginning of the post.

I think putting the post's title into that field would be more appropriate if there isn't a summary or description explicitly defined by the user.

In a lot of clients, the CW text is larger and bolder than the content, and no one ever expected someone would be putting more content in there than lot of instances allow to exist in an entire post.

Could you create a reasonable default that is more in line with what that field is for, making users who want to do what you're currently doing have to go out of their way to do it?

Thank you.

Questa voce è stata modificata (2 mesi fa)
in reply to jer

Sensitive content

Questa voce è stata modificata (2 mesi fa)
in reply to Matthias Pfefferle

A reasonable text should go here, not several hundred characters

Sensitive content

in reply to jer

Sorry, perhaps I completely misunderstood your point 🫣
in reply to jer

and btw. it is your platform GoToSocial that decides to show the full content!

We provide a reasonable summary for each post.

Here is a screenshot how the post looks on Mastodon.

Questa voce è stata modificata (2 mesi fa)
in reply to Matthias Pfefferle

That is not summary, though, that is an arbitrarily truncated portion of the article which is then repeated within the body of the post when expanded.

I'm not sure what you're trying to say regarding GoToSocial "deciding to display the full content." Are you saying that Mastodon doesn't display the full body of the post when users click into it?

in reply to jer

A long reply with better explanation of the issue

Anyway, I'll try to rephrase my point:

You are pushing a new type of content into a network that has existed for a really long time, with an ecosystem of different servers and clients where you have no control over the presentation of what you're pushing into it. Yes, I'm looking at this from a microblog perspective, because that is predominately who is going to be seeing this content—because that currently makes up most of the network.

Yes, it sucks that existing ActivityPub standards were poorly interpreted—I'm mainly looking at Mastodon here—but the reality of publishing into the fediverse now is that you have to take those existing poor interpretations into account when you decide to make a thing that pushes content to all the users who've had those decisions forced on them. I've seen development of Firefish, Iceshrimp, Iceshrimp.NET and GoToSocial developers complaining about having to do stupid things because Mastodon decided to do it that wayany times. But they do it, because they understand that if they deviate it's going to ruin the experience of others.

Whether it's a "summary" field, a "CW" field or a "subject" field, it is going to be displayed in many, many, many timelines in a way that is designed to let the user decide whether or not they want to open it to read it. What I keep encountering is WordPress posts that include 90% of the post body in the summary field (because they're not much longer). I click to expand and the whole thing is repeated with just 2 or 3 additional words that weren't included in the "summary." That is a terrible experience everywhere. Additionally, I encounter other posts where that field takes up more than the entirety of the screen on my phone. Both of those suck.

Additionally, I've never used a fediverse client that renders formatting inside that field. Mastodon's web ui may present it the way your attached screenshot does, but there are many other clients that just display it as plain text—often in a treatment that is larger and bolder than the body of the text. That reflects the reality of how it's been historically—or I guess "traditionally"—used.

If, by default, your plugin just crams in several hundred words that are not summarizing, warning, or presenting a subject—like you would put into an email—you are creating users that don't even know that they're negatively impacting the experience of people who've been using this network for almost a decade, and that sucks.

You can't do anything about the sucky "traditions" of how Mastodon and others decided to use ActivityPub, but you absolutely could do something about this sucky decision of how to use it.

My request is that you'd consider adding an explicit "fediverse post summary" field via your plugin, with a reasonable maximum length, for users to put an actual summary/warning/subject into, and map that to the ActivityPub summary field. If they decide not to put something in there, you then put something similar to the information that would go into a social media card in its place, keeping in mind that it's going to be rendered as plaintext for a lot of users.

Something like "Post from {blog name} ({blog domain}): {post title}" and maybe a short truncated bit of the first sentence if you really feel that's necessary.

Sure, maybe some users will decide to just paste the beginning of their post into that field, but that sucky decision is for them to make instead of yours.

You could absolutely improve the experience of countless long-time fediverse users, and by extension, improve their impression of the users you're helping to publish there. Right now, your users just look rude or like "bot" accounts to people like me.

Thank you for your time.

in reply to jer

I will also see if/how we can improve the auto generation of the summary... but that is general a tricky thing...
in reply to Matthias Pfefferle

Maybe just push the use of [ap_excerpt] and encourage people to actually write an excerpt.

Many people just don't know about it.