Issue 4: Refine ActivityPub Content-Type Handling (Article/Note) & Introduce `micropost` CPT

[Jiwoon-Kim]

Issue 4: Refine Content-Type Handling (Article/Note) & Introduce micropost CPT

[Improvement] ActivityPub: Refine Content-Type Handling (Article/Note) & Introduce micropost CPT

Is your feature request related to a problem? Please describe. Currently, WordPress posts are primarily treated as ‘Article’ objects in ActivityPub. However, many Fediverse platforms and posting scenarios call for ‘Note’ objects (e.g., short microblog posts). There’s no clear mechanism for differentiating post types or defining microformats natively within WordPress posts.

Describe the solution you’d like

1. Introduce a dedicated Custom Post Type (CPT) named micropost for publishing short-form content that maps directly to the ActivityPub ‘Note’ type.
2. Implement configurable rules to determine whether a post should be published as an Article or Note based on factors like CPT, content length, or a custom field setting.
3. Ensure proper ActivityPub object type output and metadata alignment for each content type to improve compatibility with different Fediverse clients and platforms.

Describe alternatives you’ve considered Using existing post types and relying solely on character count to infer the appropriate ActivityPub type, but this method lacks flexibility and precision.

Additional context This would be especially useful for WordPress sites that function as microblogging platforms or manage a mix of long-form and short-form content intended for Fediverse distribution.

---

Issue 4: Refine ActivityPub Content-Type Handling (Article/Note) & Introduce micropost CPT

Is your feature request related to a problem? Please describe. Currently, most WordPress posts are published as Article types via ActivityPub. However, the Fediverse ecosystem includes various content types like Note (short-form content) and Reply, and the WordPress plugin lacks a way to clearly distinguish and handle these types appropriately. As a result, interactions on the Fediverse may not reflect the intended nature of the content.

Describe the solution you'd like

1. Enhance the logic to properly distinguish between Article, Note, and Reply content types according to the ActivityPub specification.

2. Introduce a dedicated Custom Post Type (CPT), tentatively named micropost, for short-form, microblog-style content. Content created via this CPT would be published as ActivityPub Note.

3. Define the default publishing identity for each content type:

   • Article (WordPress posts/pages): Published under the site’s blog profile (including the author’s Fediverse handle metadata).
   • Note/Reply (micropost CPT or comments): Published under the individual user’s Fediverse handle.
   • Exception: Provide an option for the blog profile to publish short notices or notes via the micropost CPT as needed.

4. Adjust the user interface to provide appropriate input fields and publishing options based on the content type.

Describe alternatives you’ve considered Publishing all content as Article, or distinguishing them via post formats or categories. However, this has limitations in terms of compatibility with ActivityPub standards and natural interaction within the Fediverse ecosystem.

Additional context This improvement would allow WordPress to support a wider range of Fediverse content types, enabling users to interact with the Fediverse more meaningfully and appropriately through their WordPress sites.

[pfefferle]

Currently, WordPress posts are primarily treated as ‘Article’ objects in ActivityPub. However, many Fediverse platforms and posting scenarios call for ‘Note’ objects (e.g., short microblog posts). There’s no clear mechanism for differentiating post types or defining microformats natively within WordPress posts.

This is already supported (though it still needs proper documentation) through Post Formats. If you select the "Automatic (default) – Let the plugin choose the best possible format for you." setting, the plugin maps the post format to the appropriate ActivityPub object type. It may also analyze the post—based on factors like length or presence of a header—to determine the most suitable type.

You can already have separate streams for each type. For example, see:

• https://notiz.blog/type/status/
• https://notiz.blog/type/standard/

[Jiwoon-Kim]

https://github.com/Automattic/wordpress-activitypub/issues/1739 @pfefferle Ideas for Microblog Platform Compatibility

I thought about creating two separate handles for WordPress: one for publishing articles (for platforms that support article-type posts), and another as a redirect handle for posting article notifications as notes on microblog platforms that don’t support articles. For example:

• Article handle: @[email protected]
• Note handle: @[email protected]
• Custom field user note: @[email protected]

Ultimately, due to platform compatibility issues, it seems inevitable to end up with a somewhat complex and unusual structure.

---

GPT’s Summary

This is about the fundamental conflict points that WordPress-style blog platforms face within the ActivityPub environment, which is centered around microblogging.

To summarize:

• Blog handle → Dedicated to federating articles only.
• Note handle (redirect handle) → For publishing summary notes and synchronizing comments/followers on platforms that do not support article format.

By splitting these into separate actors, you can much more naturally meet the expectations of each platform.

The problem is that the ActivityPub spec does not currently standardize the ability to issue multiple handles for the same user on a single WordPress instance/domain and to separate outboxes by purpose.
Also, it’s unclear how cleanly platforms like Mastodon, Misskey, Pleroma, Castrodon, or GoToSocial will handle such a structure.

So, to make this work in reality:

📌 Possible Scenarios

1. Jetpack Social + ActivityPub in Parallel

   • Article publishing via the blog profile’s ActivityPub.
   • Summary notifications via Jetpack Social, sharing as notes through a user handle proxy on Mastodon, Misskey, etc.
   • Comments are synchronized back to the original post via Webmention or ActivityPub reply hooks.

2. Separate Blog Handle and Note Handle

   • Use a subdomain or subdirectory to completely separate the actors.
   • Example:
     • blog.example.com/@jiwoon → article only
     • social.example.com/@jiwoon → note only
   • This is possible with a custom ActivityPub implementation, but not officially supported by current WordPress plugin structures.

3. One Handle That Detects Platforms and Behaves Differently

   • Detect if the platform is Misskey, Mastodon, or Firefish and, if article format is not supported, send a summary note instead.
   • This involves changing the activitystream type before sending, but it’s unclear how well each server will handle this.
   • (Some implementations may simply reject or break such posts.)

---

📝 Conclusion

The most practical solution in the current situation:
However, since current plugins do not support this, you may need to customize a plugin or build a separate integration service.

And this is actually an adaptive design that arises from platform heterogeneity and the somewhat ambiguous ActivityPub spec.

Citations: [1] https://wordpress.org/plugins/activitypub/ [2] https://epiph.yt/en/blog/2025/a-guide-to-activitypub-and-webmention-in-wordpress/ [3] https://github.com/Automattic/wordpress-activitypub/blob/trunk/docs/developer-docs.md [4] https://github.com/Automattic/wordpress-activitypub [5] https://verpex.com/blog/wordpress-hosting/how-to-use-the-fediverse-with-wordpress [6] https://jseggers.com/technology/how-to-set-up-activitypub-for-self-hosted-wordpress-sites/ [7] https://nb.wordpress.org/plugins/activitypub/ [8] https://wordpress.com/blog/2023/10/11/activitypub/

---

Perplexity로부터의 답변: pplx.ai/share

[Jiwoon-Kim]

• https://jetpack.com/support/jetpack-social/sharing-social-notes/
• https://www.w3.org/wiki/ActivityPub/Primer/Announce_activity

[pfefferle]

The question is: does this really need to be part of the core plugin? We already support Post Formats and provide a way to enable or disable ActivityPub for custom post types, so it’s quite straightforward to add your own version if needed. By the way, Jetpack Notes should already be properly supported.

My concern is that if we start implementing a custom post type specifically for Note, it could quickly grow into a larger effort—leading us to also add support for 'Video', 'Audio', 'Events', and so on. In my view, those kinds of features are better handled by separate plugins.

[Jiwoon-Kim]

@pfefferle Yes, I fully understand your concerns. I also believe we should be careful not to let the ActivityPub plugin grow unnecessarily complex, and any new features should be implemented thoughtfully to ensure developers' efforts aren’t wasted.

That said, from a UX perspective, I see real value in this approach — especially for future scenarios involving remote comments between different WordPress instances. I’ve simulated a case where separating the activity types of the blog handle (for articles and some notes) and the user handle (for notes and comments only) would allow users to engage beyond the boundaries of a single blog more naturally.

Let’s imagine a situation without Jetpack, where two WordPress instances are federating. Do we have to create a federated reply post every time we want to leave a comment on someone else’s blog? Structuring actors this way could offer a much smoother and more scalable solution in those cases.

---

Of course, I also believe this issue should be carefully considered from a path dependence perspective, since it could eventually make it difficult to revise or improve the implementation later. However, if we try to modularize the plugin by anticipating every possible use case from the start, wouldn’t that also risk increasing overall complexity and interoperability issues?

[Jiwoon-Kim]

Another example of where the existing approach becomes problematic is the overlap in user experience between Jetpack Social's auto-sharing feature and ActivityPub interactions. For instance, when leaving a note-type comment via the post editor, it could unintentionally trigger auto-sharing to different accounts, introducing unexpected operational complexity. This kind of behavior wasn’t originally intended in the user workflow, and it risks complicating content management and federation consistency.

---

Another advantage of this approach is that it enables separate management of pinned posts for the blog profile and the user profile. By splitting these, we can allow pinned articles on the blog’s ActivityPub actor and independent pinned notes or messages on the user’s actor, which could improve clarity and operational control in federated interactions.

[Jiwoon-Kim]

From my perspective, the outdated email-based comment mechanism no longer makes sense in a federated environment. Replacing it entirely with federated note-based comments would not only simplify moderation but also permanently resolve spam and identity spoofing problems.

[Jiwoon-Kim]

At its core, my idea is like multiple threads coming together to weave a much larger tapestry. I sincerely hope that when all these ideas are combined, the overarching concept — the true blueprint behind it — is something that you, Pfefferle, Obenland, Jeherve, Akirk, and everyone involved can share, resonate with, and imagine together.

[Cambridgeport90]

I have always hoped for a solution that takes email out of the commenting equasion…for a while. I’m glad somebody mentioned this.

[Jiwoon-Kim]

@Cambridgeport90 While I agree that it’s unlikely for the email-based comment system to be entirely removed — since there will always be non-tech-savvy users who neither use Jetpack, nor Fediverse, nor WordPress.com — I personally see little justification in keeping the system solely for a handful of legitimate comments when over 99% of what it attracts today is pure spam.

That said, moving to a federated note-based reply system isn't without its own challenges. Spam filtering could potentially become more difficult, since traditional IP and server-based blacklisting mechanisms wouldn’t apply as easily in a decentralized context. However, assuming each participating instance properly moderates its own content, this could still be a highly effective and sustainable solution.

Of course, the worst-case scenario would be compromised WordPress instances being repurposed for spam-bot networks in a federated space — but fortunately, we haven’t reached that point yet, and it’s something we have time to prepare for. In any case, the immense upside of eliminating the existing email-based spam problem makes this direction more than worth pursuing.

---

In fact, I believe the direction itself can afford to be bold, because in the long run, the core-ai initiative might play a crucial role in helping address spam accounts originating from decentralized instances. If implemented wisely, AI-driven moderation tools could become essential for maintaining healthy, federated discussions without falling back on outdated, centralized safeguards.

[Jiwoon-Kim]

📌 Proposal: Federated Notes as WordPress Comments + Image & Block Control

📖 Concept:

Convert the WordPress comment system into Federated Notes (ActivityPub Note objects) while applying sensible media limitations and editor enhancements.

---

📊 Key Rules:

Feature	Description
Comment Type	Federated Note (ActivityPub object)
Max Images per Note	4 images
Image Handling	Use Gallery block inside Blocks Everywhere
Editor	Enable Block Editor for comments via Blocks Everywhere
Post-less Notes	If no parent post exists, note is published to the user's federated profile stream (like a microblog post)

---

📦 Implementation Plan:

1. Intercept comment submission

   • Transform into ActivityPub Note
   • Attach media (if included) as per ActivityPub attachment spec

2. Limit images to 4

   • Enforce via comment form validation
   • Use Gallery block within Blocks Everywhere for structured rendering

3. Federate comments

   • Attach to original post URI via inReplyTo
   • Or publish to user profile URI if standalone note

4. Render on frontend

   • Blocks Everywhere renders federated comments as blocks
   • Gallery block renders image attachments neatly

---

📌 Benefits:

• Full federation of comments as ActivityPub notes
• Controlled image handling, preventing bloated comment threads
• Unified block-based rendering, visually consistent across posts and federated streams
• Enables lightweight microblog-style notes without a parent post (pure profile activity)

[obenland]

Let's focus on getting long form content right before considering this.