Automattic
The WordPress ActivityPub plugin should ideally be built on a block editor-first environment and bundle the Blocks Everywhere plugin by default.
https://github.com/Automattic/wordpress-activitypub/issues/1828
📌 Proposal: Standardizing Block Editor Compatibility and Markdown Federation for WordPress ActivityPub
It would be ideal for the WordPress ActivityPub plugin to adopt a block editor-based environment as its standard and to bundle the Blocks Everywhere plugin for enhanced compatibility and federated content rendering.
WordPress ActivityPub plugin should ideally be built on a block editor-first environment and bundle Blocks Everywhere support by default.
Just as Mastodon and Misskey instances vary in their rich text/Markdown compatibility depending on forks and customizations (ref: fedi.tips guide), WordPress federation behavior also naturally differs based on whether the Classic Editor, Gutenberg Block Editor, or Jetpack Markdown Block is being used.
📌 Context
Federated posts containing rich formatting like Markdown, LaTeX, custom blocks from plugins or themes, must consider how these render on other WordPress instances and across the wider Fediverse.
Key formatting elements:
- Headings, bold, italic, ~~strikethrough~~, blockquotes, inline code, code blocks
- Sub/superscripts, ordered/unordered lists
For WordPress events (RSVP) or polls, a federated implementation using a Poll Block structure could help standardize rendering via Markdown fallback.
- https://docs.joinmastodon.org/methods/polls/
- https://docs.joinmastodon.org/entities/Poll/
- https://misskey-hub.net/ko/docs/for-users/features/poll/
A simple example:
https://cardpress.us/create
[](https://profile.wordpress.org/kimjiwoon)
For WordPress-to-WordPress federation, having Markdown support by default would significantly improve content parity.
📌 What I'm Proposing
The core idea is to federate WordPress Block Editor content to the Fediverse as Markdown (or HTML) while maintaining the original block structure inside WordPress.
🔧 Structure Overview
1️⃣ Write content in the WordPress Block Editor → Save block content as JSON internally
2️⃣ On ActivityPub federation
- Convert block content to Markdown or HTML
- Attach to
Noteobject
3️⃣ On the Fediverse
- Render as Markdown/HTML on platforms like Mastodon, Misskey, PeerTube
4️⃣ On receiving federated content
- Retain original JSON block data via post meta
- Optionally restore full block UI if available
📌 Benefits
✅ Clean rich-text federated posts (Markdown/LaTeX/HTML) ✅ Full block editor UI and JSON preserved internally ✅ Incoming federated notes convertible to blocks via Blocks Everywhere ✅ Future ActivityPub extensions like polls, galleries, cards handled as blocks
📌 Edge Cases to Consider
- Custom blocks from themes/plugins may not render properly when federated
- It should detect whether the recipient is a WordPress instance with compatible plugins (e.g., GatherPress, EventBridge) installed, and dynamically fetch content via API calls according to predefined formats (e.g., federated events).
- Serve appropriate content fallback based on remote instance type
Example approach:
- Detect remote instance type (WordPress or other Fediverse platform)
- If WordPress: check for specific plugin support
- Serve block-based or Markdown content dynamically
📌 Federation Note Handling
- Note summaries should ideally be plain text for maximum Fediverse compatibility
- Federated comments/replies can allow rich-text and require Blocks Everywhere plugin
- Article-type posts should be isolated via API fetch on reader or repost request
🔥 Closing Thought
This structure would offer clean compatibility across:
- WordPress block editor environments
- Fediverse platforms with varying rich text support
- Future federation scenarios like federated WordPress event RSVPs, polls, galleries, and cards
Ultimately, bundling Blocks Everywhere and a Block-to-Markdown Adapter module inside WordPress ActivityPub would position WordPress as a leading fully-compatible federated CMS within the Fediverse.
| Problem | Solution |
|---|---|
| Block → Markdown conversion | Requires a conversion library like gutenberg-to-markdown. |
| Markdown → Fediverse format differences | Identify each instance's Markdown support and apply appropriate conversion rules. |
| Comment (note reply) structure | Use a federated-reply block to connect with WordPress comment structure. |
| Preserve original block data | Store the original block JSON in post meta or a hidden field. |
📌 Additional Notes
I recommend implementing a hook such as before_federating_post in the WordPress ActivityPub plugin to:
- Convert block content to Markdown.
- Insert the Markdown/HTML into the note content.
- Save the original block JSON in the post meta.
This approach would maintain both federated compatibility and block editor integrity.
By the way — since plugins like Jetpack’s Markdown block and Blocks Everywhere already exist, a conversion library could be built on top of them.
It would also make sense to design this as a Blocks-to-Markdown Adapter submodule within the WordPress ActivityPub plugin, making it easier to extend later for federated systems like Jetpack Social, GatherPress, or future federated tools.
I see Markdown as an easy and generic, but a bit nerdy way to write posts without the need of a WYSIWYG editor. So for me Markdown is a one way solution. If you use it, then a transformation process will make HTML out of it and you can store both versions. But I do not see any advantages to transform rich HTML into Markdown with the risk to lose most of the structure.
Aside from that, I do not really see why to use the Blocks Everywhere plugin here!?
@pfefferle I get your point about Markdown — I was thinking from the perspective of users who might want a lightweight fallback editor. But I agree, converting rich HTML back to Markdown isn't very practical.
As for using Blocks Everywhere: my idea was to enable rich, structured ActivityPub comments (like images, polls, content warnings) directly in the comment area. Since the default WordPress comment field is too limited for this kind of federated interaction, a block-based comment field would allow modular, federated replies with ActivityPub-compatible formatting.
It's definitely an unconventional use, but maybe worth exploring for distributed conversations beyond simple text comments.
@pfefferle I have to admit that I don’t have a sufficiently expert-level understanding of how HTML, Markdown, LaTeX, and custom blocks interact between WordPress instances via the ActivityPub protocol. It’s possible that some of my assumptions have been conceptually off.
Perhaps I mistakenly assumed that a post written with the WordPress block editor should be federated and fully editable with the block editor on receiving instances as well. I might have also felt uncomfortable when a reply received from Mastodon opened in the classic editor rather than the block editor — since in that workflow, I believed it wouldn’t be possible to properly render things like poll blocks or content warnings (CW).
I suppose I was dissatisfied with the fact that the data structure exchanged between ActivityPub instances is asymmetric. I found myself wondering, “Why is it that when I write a post in the block editor and federate it, it only opens in the classic editor on the receiving end?” That discrepancy might have been at the heart of my concern.
Perhaps I mistakenly assumed that a post written with the WordPress block editor should be federated and fully editable with the block editor on receiving instances as well. I might have also felt uncomfortable when a reply received from Mastodon opened in the classic editor rather than the block editor — since in that workflow, I believed it wouldn’t be possible to properly render things like poll blocks or content warnings (CW).
As @jeherve already pointed out: this is indeed a bug — you shouldn’t be able to edit a post from another user. That content belongs to them and should remain unchanged.
Aside from that, we need to be cautious with remote data — that’s why we filter all incoming content through kses, which strips out JavaScript, iframes, and other potentially harmful elements that could be used for fraud. That’s why we need to use specific ActivityPub object types and attributes when sending rich content like events or polls — to ensure it’s structured, secure, and understood by other platforms.
@pfefferle Honestly, despite all that, I still think supporting the block editor for comments would be really helpful for importing rich-formatted text from external instances or for federating richly formatted notes.
I still think supporting the block editor for comments would be really helpful
While that's true, I think the same could be said for all WordPress installations out there, for all types of comments. I don't think that's an improvement that would make sense only for ActivityPub-enabled sites. That "block editor-first environment" should be WordPress, not the ActivityPub plugin alone.
As a result, I think such an improvement should be done in WordPress Core first, so plugins like ActivityPub benefit from it right away. It may be worth checking https://core.trac.wordpress.org/ to see if that's something that's been discussed already.
Until then, and if that's something that you would like to implement on your own site, you could indeed try existing tools like the Blocks Everywhere plugin to bring blocks to your readers' commenting experience.
I see the block editor (as the name implies) as an editing tool. We can store HTML in comments without the need of the blog editor, so I see no need at all, even on WordPress core site. The only edge case is if you would like to improve the user experience of blog-users writing comments.
@pfefferle Ah, I see — so it would only really be relevant in the edge case where blog users want to send rich text through comments.
I guess we’d need to properly implement plain Mastodon compatibility first, so this would have to come much later in the priority list.