Proposal: Deep Native Integration of ActivityPub for WordPress

[Jiwoon-Kim]

What

How can we harmonize the decentralized philosophy of networks like ActivityPub with the centralized convenience of integrations like Jetpack?

My idea ultimately revolves around this question:
How can we reconcile the inherently decentralized nature of ActivityPub with the benefits of centralized profile integration via services like Jetpack?

Technology should not exist for its own sake — it exists to serve meaningful purposes and provide practical value. If we cannot clearly answer why we should implement this and what value it provides, we’re merely consuming time and resources without creating lasting impact.

---

Why

Why Do We Need Native ActivityPub in WordPress?

At a glance, services like Jetpack Social already enable automatic cross-posting to platforms like Instagram, Threads, Mastodon, and Bluesky. If the sole purpose were just to distribute content, we wouldn’t necessarily need ActivityPub.

But the fundamental question is: Why implement ActivityPub natively?
This is the core of my proposal.

In my view, WordPress ActivityPub should be more than a syndication tool.
Its true potential lies in turning each WordPress site into a self-hosted social node.

Originally, WordPress was envisioned as a decentralized, open publishing platform — allowing anyone to run their own independent website. Integrating ActivityPub can extend this legacy by making every WordPress instance a fully functional, federated social hub where creators and site owners can directly interact and build communities on their own terms.

---

Key Differences Between Jetpack Social and Native ActivityPub

Jetpack Social	Native ActivityPub Integration
One-way automatic sharing	Two-way interaction (follow, like, comment, boost)
Reliance on external services	Autonomous profiles and subscriber networks within the site
Comments and reactions don’t sync back to the site	All interactions are aggregated on your own site

If your goal is pure content distribution, Jetpack Social is efficient.
But if you aim to build direct interactions and community engagement on your own site, ActivityPub is essential.

And why ActivityPub specifically?
Because it offers direct, decentralized interaction capabilities:

• For brands: Consolidate marketing channels within their own domains for stronger branding
• For individuals: Build personal digital identities and follower networks under their control
• For blogs: Expand Fediverse-based subscriber communities and feedback channels

(Bluesky excluded for now due to domain handle limitations)

---

A Practical, Purpose-Oriented Implementation

My proposal isn’t about implementing technology for novelty’s sake — it’s about offering users clear experiences and tangible benefits.

To me, WordPress Native ActivityPub is not a Jetpack Social alternative.
It’s a pragmatic, value-driven feature for creators and site owners who want to build independent communities and follower networks directly on their websites.

---

Key Recommendations for Native ActivityPub Integration in WordPress

1️⃣ Focus on Intra-WordPress Communication First

Why:
The current ActivityPub plugin focuses on external federation with Mastodon, Misskey, etc., but WordPress itself is a decentralized, self-hostable CMS.
We should prioritize seamless ActivityPub interactions between WordPress instances themselves — including single-site multi-user environments, subdomain/subdirectory multisites, and independently hosted WordPress sites.

---

2️⃣ Unified User Handle Management in Multisite Setups

In multisite environments, designate only the main domain as the ActivityPub instance for user handles.
Sub-sites can redirect ActivityPub accounts to a consolidated handle management page — e.g.
@username@instance.domain → profiles.wordpress.org/@user or fedi.wordpress.com/authors/@user

This prevents handle inflation across countless subdomains and simplifies the integration for services like Jetpack by reducing handle management to three categories:

• WordPress.org
• WordPress.com
• Custom domains

Additionally, WordPress.com/Reader’s users/@user page can be repurposed as an integrated ActivityPub profile management UI, simplifying notification handling and enabling seamless author handle switching when commenting.

Just like how, in the Instagram app, when logged into multiple profiles, holding the Follow button brings up a “Follow from another account” option, the Jetpack app could similarly allow users to follow others using their connected ActivityPub handle profiles.

This would enable seamless switching between multiple Fediverse handles within a single app environment.

---

3️⃣ Optimize the ActivityPub Publishing Structure

Current Issue:
Currently, the ActivityPub plugin posts articles to the user profile, which the blog profile then boosts (reposts). This causes discrepancies when changing post authors.

Proposed Solution:
Reverse this process —
First publish articles to the blog profile, then let user profiles boost them.
This way, switching authors or handles later only requires updating the fediverse:creator meta value.
It would also make it easier to publish third-party content via the blog profile while maintaining correct attribution in the Fediverse.

Example guide for context:
How to Change an Author in WordPress

---

How

📌 Fediverse Multi-Handle Support / Author Handle Switching UI

✔️ Why is this needed?
Currently, WordPress posts are published using a fixed handle tied to the site account. However, a single user may own multiple Fediverse handles — for example:

• a WordPress.com handle via Jetpack
• a custom domain Fediverse handle
• Mastodon
• Misskey
  and more.

By enabling handle selection per post, users could flexibly choose which identity to post under — much like selecting a “From” address in email clients.

✔️ Proposed Approach

• Store each user’s verified Fediverse handles via custom user meta or a dedicated CPT (e.g., ap_extrafield), possibly using rel="me" verification.

• → Selectable from handles connected via Jetpack Social, Gravatar-verified accounts, and others.

• In the post editor UI, provide a dropdown or selector to choose between verified handles aside from the default author handle.

• When switching handles:

  • Update the ActivityPub and OpenGraph metadata accordingly.
  • Leave other post data intact.

This is important because:
It allows users to embed multiple decentralized Fediverse identities into their WordPress profile, and publish under different handles without creating multiple WordPress instances. It moves beyond simple rel="me" profile linking — enabling active identity management across instances.

---

📌 Content Type Handling Model

✔️ Proposed Structure:

Content Type	Posting Account	Metadata
Article (Post)	Blog Profile	Includes author's Fediverse handle
Note / Reply (Short Post / Reply)	User Handle	—
Exception: Note-style post in blog	Blog Profile	—

• Introduce a dedicated micropost CPT for Notes.
• Properly differentiate between Note and Article types in ActivityPub payloads.

Behavior:

• Articles are posted from the blog profile, optionally allowing different blog profiles on multisite setups.
• The author’s Fediverse handle is embedded in the post metadata and OpenGraph.
• Notes and Replies are primarily posted from the user’s handle.
• Special cases: If a short-form post needs to be published via the blog profile (e.g., site news), allow it, using the micropost CPT.

---

📌 Author Page Frontend UI

✔️ Why?
To separate and display different content types (Posts, Comments, Notes, Replies) within the author profile page, and to optionally display content fetched from external Fediverse instances (remote blogs or users).

✔️ Proposed Features:

• Implement an ActivityPub remote_user page to fetch and display remote notes/posts.
• Support reposting or quoting remote content (images hotlinked, text saved locally — immutable, deletable only).
• Prevent duplicate reposts across multiple accounts.

In practice:

• The author page or remote_user page should be able to fetch and display content lists from other Fediverse servers' blogs or user accounts.

• For external content:

  • Text is saved locally (read-only, cannot be edited after import, deletable only)
  • Images are hotlinked to the original source.
  • Prevent duplicate reposts if multiple users repost the same item.
  • When viewing an article from an external instance’s proxy user, the WordPress Reader view is embedded for a consistent reading experience.

---

📌 Homepage / Postpage / Feedpage Structure

✔️ Feed structure proposal:

• Homepage — displays site posts and optionally federated content.
• Postpage (blog/news) — displays Article-type content.
• Feedpage (profile/note/Pixelfed style) — displays user Notes, Replies, and federated content.

---

📌 Conclusion

The ActivityPub feature for WordPress should be designed not as a simple bridge to external Fediverse platforms but as a framework to turn WordPress itself into a fully federated, independent Fediverse instance.

By supporting:

• Multisite
• Multi-handle
• Multi-content-type

it enables rich decentralized publishing networks directly from WordPress installations.

Closing Thought

WordPress’ original vision was “Democratize Publishing”.
Integrating ActivityPub natively isn’t just a technical enhancement — it’s a way to return to those roots in a modern, federated web where creators and site owners control their identities, interactions, and communities.

Let’s build tools that serve people’s needs, not just technical possibilities.

[Jiwoon-Kim]

When distributing content to a Mastodon account via Jetpack Social’s auto-share feature,
it may be ideal to boost the post from the WordPress Fediverse profile’s Mastodon proxy.
This approach helps prevent data duplication on Mastodon servers and avoids fragmenting followers, thereby preserving the value and authority of the WordPress Fediverse profile.

However, in the case of Misskey, it appears that handles in the form of @sub.wordpress.com@sub.wordpress.com are not properly supported.
Alternative blog handles such as @sub@sub.wordpress.com or aliases like @news, @feed, or @article may be necessary.

[obenland]

Thank you for your detailed thoughts on ActivityPub integration. I can see the effort you've put into this proposal.
I understand there may be language barriers, but I'd like to offer feedback on making future discussions more effective. GitHub issues work best when they are:

• Focused on a single, specific request.
• Concise and scannable for quick triage.
• Clear about the desired outcome.

Long-form proposals like this, while thoughtful, are challenging for maintainers to process efficiently.
Would you consider breaking this into smaller, focused issues? For example, separate discussions for handle management, content types, or UI improvements? This would help us give each aspect proper attention and make meaningful progress.
Thanks for understanding.

[Jiwoon-Kim]

@obenland Thank you for your thoughtful feedback.
Personally, I wanted to avoid creating multiple scattered issues and preferred to submit a single well-structured, comprehensive proposal for clarity and context.

But I completely understand the need for efficient issue management on GitHub.
I’ll work on breaking this down into smaller, focused issues so that each part can be reviewed and discussed more effectively.

Appreciate your understanding — I’ll follow up with reorganized topics soon.

[obenland]

Closing in favor of the tickets listed above ^