Feature Request: Implement WordPress-to-WordPress `Announce` (Reblog) Functionality via ActivityPub

[Jiwoon-Kim]

What

Based on your provided content, here’s a structured request summary for implementing WordPress-to-WordPress Announce functionality via the ActivityPub protocol.

---

📌 Core Request:

Enable a native "Reblog" function between WordPress sites using the ActivityPub protocol’s Announce activity — replacing simple oEmbed-based embedding with true federation-based content sharing.

---

📌 Current Situation & Issues:

1. Limitations of Jetpack Reblog:
   Jetpack’s current reblog function does not consider ActivityPub. It simply embeds the original post’s URL as an oEmbed/OpenGraph-based preview.
   → For example, when reblogging a post from kowporg.wordpress.com (with ActivityPub enabled) to travel-in-busan.com (self-hosted with ActivityPub plugin installed), it embeds via oEmbed rather than issuing an Announce.

2. Incompatibility with Fediverse:
   The embed approach differs from how the Fediverse handles content sharing via Announce (Boost, Renote, Repost).
   This leads to duplicated or awkward post appearances within timelines on platforms like Mastodon and Misskey.

3. Visual Issues with Embeds:
   WordPress’s oEmbed sometimes fetches the full page layout (including headers and sidebars) or suffers from layout/font conflicts (e.g. Avada theme, Font Awesome rendering issues), breaking post appearance.

---

📌 Expected Benefits (if implemented):

1. Native Federation:
   When reblogging from kowporg.wordpress.com using an account on travel-in-busan.com, it should trigger an ActivityPub Announce activity from the local actor — seamlessly distributing the post to followers' timelines.

2. Avoiding Duplicate/Redundant Posts:
   Prevents redundant embed-card posts and creates a more natural Fediverse user experience.

3. Flexible Content Sharing by Post Type:

   • WordPress to WordPress (Article type): Share the full post via Announce in a native reblog manner.
   • WordPress to Microblogging Platforms (Note type): Share as a link card with a post summary and source link — optimized for each platform’s UX (optional feature).

---

📌 Implementation Proposal & Considerations:

1. Prioritize Announce Handling:
   When both WordPress instances have ActivityPub enabled, detect a reblog action and generate an Announce activity instead of embedding.

   Example ActivityPub JSON:

   {
     "@context": "https://www.w3.org/ns/activitystreams",
     "type": "Announce",
     "actor": "https://travel-in-busan.com/users/username",
     "object": "https://kowporg.wordpress.com/2025/05/17/wordpress-useful-links/"
   }

2. Integrate with Jetpack Reblog:
   Detect when Jetpack’s reblog feature is used and optionally replace (or supplement) the current embed method with ActivityPub Announce logic.

3. Image Handling Options (User-Configurable):
   Provide options for how images in reblogged posts are handled (similar to Naver Blog’s “본문 스크랩(full content scrap)” / “링크 스크랩(link scrap)” options or Mastodon/Misskey’s media caching settings).

   • Full Content Announce (Image Local Save):
     Fetch and store both text and images on the local server. Ensures content persistence even if the source is deleted. (like Naver "본문 스크랩")

   • Summary/Link Announce (Image Remote Link):
     Share a summary or excerpt with images linked from the source server. Reduces local server load but risks broken images if the source disappears.

   • Link Card Announce:
     Show only the post title, thumbnail, and link in a card layout. (like Naver "링크 스크랩")

   • (Optional) Disable Announce:
     Fall back to the current embed method only.

4. Internal Server Handling:
   When reblogging within the same WordPress installation, instead of embedding the source post via oEmbed, refer to the Announced post’s ID and display it cleanly as a native post.

---

📌 Conclusion:

By implementing the ActivityPub Announce function into WordPress’s reblogging system, we can bring WordPress sites closer to seamless Fediverse integration, improving both content federation and user experience.
It’s crucial to evolve from simple embedding to true social federation when sharing content between WordPress instances.

---

Why

Sure — here’s your detailed conversation flow translated into natural, structured English while preserving technical accuracy:

---

Alright, I’ll reorganize the content you provided in the order it appeared during our conversation:

---

1. Defining "Reblog" and "Reply" in ActivityPub

• Reblog: Implemented as an Announce activity in ActivityPub.
  Examples: Boost in Mastodon, Renote in Misskey, Repost in Threads, Boost in PixelFed, Announce in Pleroma/Akkoma.
  Example ActivityPub JSON:

  {
    "@context": "https://www.w3.org/ns/activitystreams",
    "type": "Announce",
    "actor": "https://example.com/users/jiwoon",
    "object": "https://example.com/users/someone/statuses/123"
  }

• Reply: Implemented using the inReplyTo field.
  Example ActivityPub JSON:

  {
    "@context": "https://www.w3.org/ns/activitystreams",
    "type": "Create",
    "actor": "https://example.com/users/jiwoon",
    "object": {
      "type": "Note",
      "content": "Great post — thanks for sharing!",
      "inReplyTo": "https://example.com/users/someone/statuses/123"
    }
  }

  In the WordPress ActivityPub plugin, this is mapped to a comment.

---

2. How Jetpack Reblog Currently Works and the Problem Raised

• Scenario:
  Attempted to reblog a post from kowporg.wordpress.com to travel-in-busan.com using Jetpack’s reblog function.

• Result:
  Instead of an Announce, it embedded the post as a link card (oEmbed/OpenGraph style preview).

• How Jetpack Reblog Works:
  It generates a card-style preview using OpenGraph + oEmbed. It doesn’t copy the original post content — it only embeds a link preview.

• Problem:
  This differs from an ActivityPub Announce, which would natively share the original post into the reblogging account’s timeline. Jetpack’s method only creates a visual card.

• Current Workaround:
  If you want it as a standalone post, you must manually create a new post and add the original link.

---

3. Expected Behavior When Linking WordPress.com and Self-Hosted WordPress via ActivityPub

• Current Setup:

  • kowporg.wordpress.com: ActivityPub enabled (address: @[kowporg.wordpress.com@kowporg.wordpress.com](mailto:kowporg.wordpress.com@kowporg.wordpress.com)).
  • travel-in-busan.com: Self-hosted WordPress site with the ActivityPub plugin installed and connected (address assumed as @[travel-in-busan.com@travel-in-busan.com](mailto:travel-in-busan.com@travel-in-busan.com)).

• Desired Behavior:
  When the travel-in-busan.com account boosts (Announces) a post from kowporg.wordpress.com, it should federate as an ActivityPub Announce — not as an embed card — to avoid content duplication.

• Key Question:
  When both sites support ActivityPub, can Jetpack Reblog be handled as an Announce activity in the ActivityPub protocol?

---

4. Federation Handling Between WordPress 'Article' and Microblog 'Note' Types

• Context:
  The ActivityPub protocol treats 'Note' and 'Article' types differently during federation.

• WordPress ActivityPub Plugin:
  By default, posts are federated as Article types.

• Microblogging Platforms (Misskey, Mastodon, etc.):
  Primarily use the Note type.

• Suggestion:

  • Between WordPress sites: Use Announce for Article type posts.
  • From WordPress to microblogging platforms:
    Share as a link card + excerpt + page link for a smoother UX.

  In short: prioritize ActivityPub Announce between WordPress sites, and publish in a separate, compatible format for microblogs.

---

5. Comparison with Naver Blog’s 'Share' Function and the Importance of ActivityPub Announce

• Naver Blog Share Function:

  • Link Scrap: A link preview card (thumbnail + title + description + URL), similar to oEmbed.
  • Content Scrap: Copies the full post content (text, images, etc.) to your own blog.

• Limitation of WordPress’s oEmbed Method:
  No concept of federation. It feels out of place in federated social network ecosystems where ActivityPub’s Announce is the native approach.

---

6. Image Handling Options When Announcing

• Full Announce (Content + Images Stored Locally):
  Similar to Naver’s “Content Scrap” — download and save images to your server. Ensures preservation even if the original source is lost.

• Summary Announce (Excerpt + Link + Original Image Link):
  Like a renote. Uses the original server image URL. Risk: broken images if the source server goes down.

• Link Card Announce (Title + Thumbnail + Link):
  Minimal server load, similar to Naver’s “Link Scrap.”

• Disable Announce (Embed Only):
  Keep the current behavior.

• Suggestion:
  Just like Mastodon/Misskey’s “media cache” option, WordPress ActivityPub could benefit from configurable image caching for Announce actions — improving both server management and federation UX consistency.

---

7. Core Objective and Internal Handling Proposal

• Primary Goal:
  Prefer ActivityPub Announce federation over embed cards.

• WordPress-to-WordPress Federation:
  Implement direct Announce behavior for reblogs between WordPress instances.

---

If you'd like, I can help you translate the remaining part or draft a spec proposal for your WordPress ActivityPub setup as well. Would you like me to do that too?

How

No response

[Jiwoon-Kim]

Okay, here's the English version of the suggestions and discussion points for the GitHub issue:

---

Suggested Title: Proposals and Discussion Points for Enhancing WordPress ActivityPub Integration

Introduction:
Based on some experiments and deliberations regarding the WordPress ActivityPub plugin and WordPress.com's federation features, I'd like to share some proposals for future development directions and areas that require further discussion.

1. Proposal for WordPress.com as a Centralized Fediverse Account Integration & Relay Server

• Current Situation & Idea:
  Currently, WordPress.com seems to generate Fediverse handles on a per-blog basis. However, considering interactions with external Fediverse instances, I propose that WordPress.com could act as a form of centralized relay server or an integrated management point.
• Specific URL Structure Examples (inspired by Misskey/Threads):
  • Instance Info: fedi.wordpress.com/instance-info/mastodon.social
  • User Profile (Misskey style): fedi.wordpress.com/@thaumiel999@mastodon.social
  • User Profile (Threads style): fedi.wordpress.com/fediverse_profile/@thaumiel999@mastodon.social
• Expected Benefits:
  • Could simplify the implementation and management of following/follower relationships.
  • Could open up possibilities for self-hosted WordPress site operators to also add their sites to this relay server to utilize federation features.
• Points of Concern/Deliberation:
  • Handling Fediverse handles for WordPress.com users/blogs: For WordPress.com subdomains, unifying user handles into a single format might be beneficial for data structure optimization. However, the number of interaction scenarios with external instances is vast, and there are many factors to consider, making it complex.

2. WordPress Profile Unification and its Relation to Federation ID

• Idea and Concerns:
  • I've considered the idea of using existing WordPress.com reader profiles (e.g., https://wordpress.com/reader/users/kimjiwoon96) as Fediverse profiles.
  • However, integrating self-hosted WordPress, WordPress.com, and WordPress.org profiles is a significant undertaking in itself.
  • Paradoxically, this internal WordPress ecosystem profile unification might be simpler to address if the complexities of extending them into full-fledged Federation IDs are initially set aside.

3. Enhancing Federated Reply Management using the Block Editor

• WordPress's Strength: The block editor has the potential to allow linking, quoting, editing, and managing various federated replies (external Fediverse comments) directly within a post's comment section or even the post body.

• Suggestion:

  • Limit Placement of Federated Reply (or activitypub/reply) Blocks: To avoid confusion, it might be beneficial for UX to enforce that a dedicated block for embedding or representing a specific Fediverse reply can only be placed once within the context of a single original comment it's replying to.

• Usage Example (Illustrating complex Fediverse interactions within a comment thread):
  The block editor could be used to structure and display complex Fediverse interactions within WordPress comments as follows:

  <p>reply</p>
              <p>@kowporg.wordpress.com@kowporg.wordpress.com @thaumiel999@mastodon.social @thaumiel999@misskey.io</p>
              ```
  

• Expected Benefits: As shown above, the block editor could enable the systematic representation and management of complex Fediverse conversation threads within WordPress.

Conclusion:
I hope these proposals and points for consideration will contribute to the advancement of the WordPress and ActivityPub ecosystem. I particularly look forward to in-depth discussions on leveraging the role of WordPress.com and the potential of the block editor.

---

[obenland]

I expect this will become possible once following works and there's a UI for it.