Getting started with ActivityPub on WordPress just got a lot easier. A new guided onboarding experience is now part of the plugin, designed to help you configure key settings and understand how your site connects to the Fediverse—from the moment you activate it.

Whether you’re new to ActivityPub or just setting things up again, the onboarding flow helps you make informed choices around visibility, content formatting, and profile setup. It’s built to give you confidence that your content is reaching the right audiences in the right way.

Tailored for You

The plugin now adapts its behavior based on the caching plugins you have installed. You’ll also find clearer guidance if you’re using Surge, and an option to fine-tune how your content is tailored for browsers versus Fediverse services.

We’ve moved profile-related settings out of the welcome page and into new dashboard widgets, so they’re easier to find and update. And to make the learning curve smoother, the Help tab now includes a section explaining how ActivityPub works on the users page.

Media, Previews, and Performance

Beyond onboarding, this release adds support for audio and video attachments in ActivityPub embeds and previews. Posts shared to the Fediverse can now include up to four images, and you can choose how many to include on a per-post basis. Editor previews have also been improved—they now show media even if the post hasn’t been published yet.

For performance, author profiles now return a smaller set of extra fields (up to 20) to avoid bloated responses, and invalid items in the Outbox are skipped gracefully instead of causing errors.

Designed to Grow With You

This update also brings better mobile support for settings pages, improved documentation, and more robust error handling for things like missing or misformatted Outbox requests. And for developers, several filters and hooks have been updated or deprecated to make future work smoother and more predictable.

If you’ve been curious about joining the Fediverse or connecting your blog in a more structured way, now’s a great time to try it. Just activate the plugin and let the onboarding guide you through the rest.

Tried the new onboarding? Let us know how it worked for you and what you’d like to see improved.

Full Changelog

Added

• ActivityPub embeds now support audios, videos, and up to 4 images.
• Added a check to make sure we only attempt to embed activity objects, when processing fallback embeds.
• Add setting to enable or disable how content is tailored for browsers and Fediverse services.
• Adjusted the plugin’s default behavior based on the caching plugins installed.
• A guided onboarding flow after plugin activation to help users make key setup decisions and understand Fediverse concepts.
• Author profiles will cap the amount of extra fields they return to 20, to avoid response size errors in clients.
• Fediverse Preview in the Editor now also supports video and audio attachments.
• Guidance for configuring Surge to support ActivityPub caching.
• Help tab section explaining ActivityPub capabilities on the users page.
• Profile sections have been moved from the Welcome page to new Dashboard widgets for easier access.
• The ActivityPub blog news feed to WordPress dashboard.
• The Outbox now skips invalid items instead of trying to process them for output and encountering an error.

Changed

• Batch processing jobs can now be scheduled with individual hooks.
• Better error handling when other servers request Outbox items in the wrong format, and 404 pages now show correctly.
• Fediverse Previews in the Block Editor now show media items, even if the post has not been published yet.
• Hide interaction buttons in emails when the Classic Editor is used.
• Improve compatibility with third-party caching plugins by sending a Vary header.
• Much more comprehensive plugin documentation in the Help tab of ActivityPub Settings.
• NodeInfo endpoint response now correctly formats localPosts values.
• Reactions block heading now uses Core’s heading block with all its customization options.
• Settings pages are now more mobile-friendly with more space and easier scrolling.
• The number of images shared to the Fediverse can now be chosen on a per-post basis.
• Updated default max attachment count to four, creating better-looking gallery grids for posts with 4 or more images.
• Use a dedicated hook for the “Dismiss Welcome Page Welcome” link.
• Use FEP-c180 schema for error responses.
• Use Audio and Video type for Attachments, instead of the very generic Document type.

Deprecated

• Deprecated rest_activitypub_outbox_query filter in favor of activitypub_rest_outbox_query. Deprecated activitypub_outbox_post action in favor of activitypub_rest_outbox_post.

Fixed

• Broken avatars in the Reactions and Follower block are now replaced with the default avatar.
• Email notifications for interactions with Brid.gy actors no longer trigger PHP Warnings.
• Improved support for users from more Fediverse platforms in email notifications.
• Improved the handling of Shares and Boosts.
• Issue preventing “Receive reblogs (boosts)” setting from being properly saved.
• Mention emails will no longer be sent for reply Activities.
• Prevent accidental follower removal by resetting errors properly.
• Properly remove retries schedules, with the invalidation of an Outbox-Item.
• The blog profile can no longer be queried when the blog actor option is disabled.

Downloads

• WordPress.org: downloads.wordpress.org/plugin…
• GitHub: github.com/Automattic/wordpres…

I know that title might seem controversial, so let's dive in. Right now, here’s the landscape of federated protocols:

• ActivityPub - The shining star of this article.
• OStatus - Mostly deprecated in favour of ActivityPub.
• Diaspora - Exclusive to Diaspora, limiting interoperability.
• Nostr - Infamous due to problematic user behaviour, unlikely to achieve significant interoperability.
• Matrix - Could theoretically support social media use-cases but currently doesn't.
• ATProto - Technically promising, yet hampered by corporate handling and mistrust from the open-source community.

Ultimately, that leaves us with ActivityPub. Everything else either lacks widespread adoption, doesn’t support common social media scenarios, or is effectively proprietary despite being open-source. For those who prioritize open-source solutions, ActivityPub is essentially the only viable option.

The Good

While I’m about to critique ActivityPub extensively, it undeniably has strong points:

• Interoperability: The core idea is genuinely powerful. Using your Mastodon account to comment on a Lemmy post—or even reading this blog post on your preferred instance—is genuinely amazing. Different instances can display content uniquely, allowing users to interact in a way tailored to their platform.
• Human-readable JSON: While some might underestimate this, JSON's human readability makes debugging and understanding ActivityPub interactions straightforward.
• Extensible: Custom properties and types can extend functionality beyond initial design limitations, ensuring future flexibility.

The Bad

Most issues with ActivityPub stem from one critical flaw: much of its behaviour is undefined. The core types and activities allow interactions that make little practical sense. For instance, the Like activity should be simple—you like something. But, in ActivityPub, you can "like" another Like activity, creating infinite loops of nonsensical interactions.

This flexibility leads to a significant problem: no two implementations behave identically. Developers resort to hacks and guesswork to interpret undefined behaviour. Ideally, ActivityPub would strictly define interactions for core types, enabling implementations (Mastodon, Lemmy, Pleroma, etc.) to focus solely on presentation or extending functionality, knowing basic interactions remain consistent across platforms.

A practical example is the confusion around private messages. Two competing methods have emerged: a custom ChatMessage type not officially supported by ActivityPub (used by Lemmy, Pleroma and others), and an alternate "standard" using a Note object that excludes the public audience but explicitly mentions recipients (used by Mastodon and others). This ambiguity creates compatibility nightmares.

Another example I personally encountered was a frustrating issue while implementing ActivityPub for this blog: updating a post propagated to Lemmy but not Mastodon. Despite the Update activity being accepted, Mastodon silently rejected it unless the updated timestamp changed—a logical but unofficial requirement. Developers must track down subtle implementation details that aren't formally documented, significantly complicating adoption and usage.

The Ugly

Privacy is virtually non-existent. When another server federates with yours, it receives all public activities, which might seem harmless initially. However, what happens if you mistakenly share sensitive information publicly? In theory, deleting a post propagates across the network, but real-world scenarios vary greatly—from technical glitches to outright malicious actors ignoring delete requests. Ensuring robust privacy requires substantial protocol-level changes, such as introducing end-to-end encryption—something notoriously complex to implement, as evidenced by Matrix’s struggles.

Another significant flaw is impersonation vulnerability. ActivityPub itself has no built-in authentication mechanism, meaning anyone could theoretically impersonate any user. Although most implementations use the HTTP Signatures standard to address this, ActivityPub itself remains incomplete in terms of essential security features. The standard openly acknowledges:

Unfortunately at the time of standardization, there are no strongly agreed upon mechanisms for authentication.

Conclusion

ActivityPub, particularly its vocabulary rules (ActivityStreams), remains a half-finished protocol. Its effectiveness depends heavily on individual implementation choices, creating problematic discrepancies—such as the inability to reliably send private messages between Mastodon and Lemmy users. Moreover, simple human errors or software oversights can unintentionally expose private information, as recently demonstrated when new Fediverse software mishandled Mastodon-style private messages and displayed them publicly.

The solution? ActivityPub needs a clearly defined second iteration—an ActivityPub v2—that eliminates ambiguity, standardizes behaviour strictly, and provides essential security measures. Certain issues, especially privacy, may never be fully resolved within the protocol, but increased clarity and stricter rules would significantly mitigate existing risks.

This doesn’t mean we should abandon ActivityPub, but rather, we must work collectively to standardize it further, making it more secure and less error-prone.

What are your thoughts on ActivityPub? Have you developed something using it? Are you planning to? Let me know in the comments!

#ActivityPub "The Good, the Bad and the Ugly" is a good article by @dominik

chrastecky.dev/technology/acti…

The two mentioned examples in "The Bad" are long-time issues that were also discussed at #SocialHub. I just responded to one of them on the forum..

The #Mastodon Update(Note) quirk. socialhub.activitypub.rocks/t/…

The other one is around Direct Messages which are a hack (a Note with special sauce). #LitePub specifies ChatMessage object type here, which is the intended way to extend the protocol. #FEP

`Update(Note)` quirk

This article published two weeks ago mentions the issue (highlight mine) .. Another example I personally encountered was a frustrating issue while implementing ActivityPub for this blog: updating a post propagated to Lemmy but not Mastodon.

^SocialHub

Dominik Chrástecký - Blog

2025-04-16 20:15:00

dch_blog

ActivityPub: The Good, the Bad and the Ugly

I know that title might seem controversial, so let's dive in. Right now, here’s the landscape of federated protocols:

• ActivityPub - The shining star of this article.
• OStatus - Mostly deprecated in favour of ActivityPub.
• Diaspora - Exclusive to Diaspora, limiting interoperability.
• Nostr - Infamous due to problematic user behaviour, unlikely to achieve significant interoperability.
• Matrix - Could theoretically support social media use-cases but currently doesn't.
• ATProto - Technically promising, yet hampered by corporate handling and mistrust from the open-source community.

Ultimately, that leaves us with ActivityPub. Everything else either lacks widespread adoption, doesn’t support common social media scenarios, or is effectively proprietary despite being open-source. For those who prioritize open-source solutions, ActivityPub is essentially the only viable option.

The Good

While I’m about to critique ActivityPub extensively, it undeniably has strong points:

• Interoperability: The core idea is genuinely powerful. Using your Mastodon account to comment on a Lemmy post—or even reading this blog post on your preferred instance—is genuinely amazing. Different instances can display content uniquely, allowing users to interact in a way tailored to their platform.
• Human-readable JSON: While some might underestimate this, JSON's human readability makes debugging and understanding ActivityPub interactions straightforward.
• Extensible: Custom properties and types can extend functionality beyond initial design limitations, ensuring future flexibility.

The Bad

Most issues with ActivityPub stem from one critical flaw: much of its behaviour is undefined. The core types and activities allow interactions that make little practical sense. For instance, the Like activity should be simple—you like something. But, in ActivityPub, you can "like" another Like activity, creating infinite loops of nonsensical interactions.

This flexibility leads to a significant problem: no two implementations behave identically. Developers resort to hacks and guesswork to interpret undefined behaviour. Ideally, ActivityPub would strictly define interactions for core types, enabling implementations (Mastodon, Lemmy, Pleroma, etc.) to focus solely on presentation or extending functionality, knowing basic interactions remain consistent across platforms.

A practical example is the confusion around private messages. Two competing methods have emerged: a custom ChatMessage type not officially supported by ActivityPub (used by Lemmy, Pleroma and others), and an alternate "standard" using a Note object that excludes the public audience but explicitly mentions recipients (used by Mastodon and others). This ambiguity creates compatibility nightmares.

Another example I personally encountered was a frustrating issue while implementing ActivityPub for this blog: updating a post propagated to Lemmy but not Mastodon. Despite the Update activity being accepted, Mastodon silently rejected it unless the updated timestamp changed—a logical but unofficial requirement. Developers must track down subtle implementation details that aren't formally documented, significantly complicating adoption and usage.

The Ugly

Privacy is virtually non-existent. When another server federates with yours, it receives all public activities, which might seem harmless initially. However, what happens if you mistakenly share sensitive information publicly? In theory, deleting a post propagates across the network, but real-world scenarios vary greatly—from technical glitches to outright malicious actors ignoring delete requests. Ensuring robust privacy requires substantial protocol-level changes, such as introducing end-to-end encryption—something notoriously complex to implement, as evidenced by Matrix’s struggles.

Another significant flaw is impersonation vulnerability. ActivityPub itself has no built-in authentication mechanism, meaning anyone could theoretically impersonate any user. Although most implementations use the HTTP Signatures standard to address this, ActivityPub itself remains incomplete in terms of essential security features. The standard openly acknowledges:

Unfortunately at the time of standardization, there are no strongly agreed upon mechanisms for authentication.

Conclusion

ActivityPub, particularly its vocabulary rules (ActivityStreams), remains a half-finished protocol. Its effectiveness depends heavily on individual implementation choices, creating problematic discrepancies—such as the inability to reliably send private messages between Mastodon and Lemmy users. Moreover, simple human errors or software oversights can unintentionally expose private information, as recently demonstrated when new Fediverse software mishandled Mastodon-style private messages and displayed them publicly.

The solution? ActivityPub needs a clearly defined second iteration—an ActivityPub v2—that eliminates ambiguity, standardizes behaviour strictly, and provides essential security measures. Certain issues, especially privacy, may never be fully resolved within the protocol, but increased clarity and stricter rules would significantly mitigate existing risks.

This doesn’t mean we should abandon ActivityPub, but rather, we must work collectively to standardize it further, making it more secure and less error-prone.

What are your thoughts on ActivityPub? Have you developed something using it? Are you planning to? Let me know in the comments!

ActivityPub

The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format.

^www.w3.org

🏕️ my adventures in #selfhosting - day 128 (a bit Clueless edition) 🎬​

Bonjour Fedi friends!

I'm having a really interesting week: 4 adult caretakers in a house with 3 little children... as I admitted to someone on here, self-hosting is FAR easier than being a referee in fights about LEGOs 😅​

Now, whenever the cousins are busy playing in the garden, I try to do a bit of work, namely: figuring out #PeerTube from the POV of a self-hoster.

Yesterday I finally understood how I could create a user account (other than "root" - the superuser created during the PeerTube installation).

Today I'm busy trying to solve another problem: how do you tell your followers you've moved to a new instance? Because yes, PeerTube is powered by #ActivityPub, but it doesn't support the MOVE function.

I rarely posted on my MakerTube account and only have 150 subscribers, who followed me when reading about it on my blog post about PeerTube.

But I have to admit, the whole "following" thing is really convoluted on PeerTube because you can follow an entire account or specific channels. And I'm a little lost regarding how I notify my followers about the change.

If you have any suggestions, I'm all ears!

Oh and some news for you first... here is my new PeerTube home: videos.elenarossini.com/a/ele/…

Special thanks to ​
@yunohost
for empowering me to set up my own instance ❤️​

#MySoCalledSudoLife #video

Progress on the FEP for Event objects

The FEP-8a8e (Fediverse Enhancement Proposal) had at lot of progress in the last months. In the meantime, the document has become somewhat more extensive than originally planned, but contains not only instructions for new features that have to be tediously implemented, but also a lot of advice and points that should provide orientation for developers of Fediverse applications that support events.

It now covers:

• Required attributes
• Events with Open End
• Timezone
• Physical and Virtual Locations
• Event status
• RSVP (Attendee Management)
• Event Banner and Poster Images
• Event Categories
• Discoverability
• Event Organizers
• Upcoming Events Collection for ActivityPub actors
• Term Definitions

Many thanks again to all reviewers and co-editors:

@lesion @heiglandreas @naturzukunft @laurin

We warmly welcome further feedback from the communities of #Friendica, #Mobilizon, #Hubzilla, and other Fediverse platforms supporting events.
If you’re working on such an application or are part of these communities, your insights would be very valuable! @developers @mobilizon

#ActivityPub #Fediverse #FEP

Publicacion scheduled for monday 2025-02-03 18:00
Dear studi0 community

We decided to add an #element #matrix #privateSpace #chatRoom to our setup and called it: tupambaeORGstudi0
Please be patient in any case as this is complete #Neuland for the admin in charge.

At least he managed to onboard a filmmaker, photographer and writer as the first step to understand how invites work!

So, hi there!
.. self-hosting based in Paris, France newbie @ elena@aseachange.com, director of The Illusionists documentary and #FOSDEM2025 traveler for your new proyect:
💌 #TheFutureIsFederated
The one who host's here 📷 photos apparently at @ ele@photos.elenarossini.com.

To begin with we created 3 rooms:

• studi0 community
• APP tutorials

  
  and as the first officialy approved project
  @jesuiSatire …ᘛ⁐̤ᕐᐷ managed to trigger:

• Projekt wahlKarnavalKrampf #foFritzMertz

In the @EDIT | don't follow! profile we creatd already a postString for that Projekt with a very limited time horizon.

Next step will probably be creating a activityPub #podcast handle on cast.tupambae.com by @utopiArte, the admin over there, as content colection and conversation about the idea itself in the EDITing post is already up and running.
Part of the details concerning the cast domain is to figure out how to organize the tools #castopod gives us at hand as it looks like it has quite interesting options to organize cooperation, as stated briefly in a tutorial page created on that site, result of the #learningBYdoing process while installing it: brief Castopod tutorial

Last but not least, we are still trying to drag @lizzischmidt the creator and promotor of the #sundayGimp community experience that is alive and running for over a decade on #diaspora* on to our shores, but federation with diaspora, from a technical point of view, definitely has seen better times in the past. Maybe this very cross community chat option, added right here and now, can help to improve the communication for all of us.

This inicial publication will federate quite well out into the vast space of the #fediVerse, but to see comments from the diaspora bubble and the #activityPub sphear, youll have to visit this original page on this friendica server.
Unless of course you are friendican yourself.

So, with no more further introduction, let's jam the #fediFolks!

tube.tchncs.de/w/u7q2ddpNfv6cU…

EDITion | EN

2025-02-01 11:27:57

friendica

edition v.01a

@ studio0@tumpambae.org
Projekt [Vorschlag passend zum] #Karnavalswahlkrampf2025
#communityMediaProjektIdee iniziert von @aiquez und @jesuiSatire …ᘛ⁐̤ᕐᐷ basierend auf einer Idee von @aiquez aufgrund eines toots von @ chrisstoecker@mastodon.social

#FallVonMerz
Delenda die Ideen des foFritz Merz by @aiquez

ein Lied odar gar mehrere Lieder bis ihn zu einem ganzen Album:
-> Soundtrack zur Wahl/Nichtwahl von Merz / CXU

Themen:
Asozialität
Elitismus von Merz.

- hoffnung auf #FallVonMerz
- Ideen des Merz (sind Shyze ..)

-> Fall von #Brandmauer
-> #FallDesMerz #Merz epic fail

soundtrack [01(?)]:
Vorschlag -> Zeilen einer Strophe

Hochgeflogen
auf #BlackRock gelandet
alle Demokraten verprellt
sich Freundschaft mit Alice eingehandelt
#NiemandWillMerz und seine unfähige Rasselbande .. (Linnemann, Klöckner Spahn, CXU)
deren w'politische Ufähigkeit passt auf keinen Bierdeckel

in edition