Automattic
Markdown Compatibility Across Federated Instances and WordPress ActivityPub Integration
I wanted to raise a suggestion regarding Markdown support within federated networks and its relevance to WordPress ActivityPub integration.
Some Mastodon instances currently support Markdown formatting:
- https://mastodon.social/@[email protected]/104669966291639888
- https://hello.2heng.xin/@mashiro/104669996625426621
In contrast, platforms like Misskey support Markdown partially or not at all, depending on the instance:
There have also been ongoing discussions in the Mastodon community regarding rich text and Markdown:
- https://github.com/mastodon/mastodon/issues/853
- https://github.com/mastodon/mastodon/issues/761
- https://glitch-soc.github.io/docs/features/rich-text/
Given that WordPress already supports both the Block Editor and the Classic Editor — both of which can handle Markdown or Markdown-like input through plugins — achieving compatibility between federated WordPress instances should be relatively straightforward.
I believe the main focus would be ensuring ActivityPub compatibility for plugins like GatherPress and EventBridge, which could greatly benefit from federated event content sharing in a Markdown-compatible format.
Would love to hear your thoughts on whether this might be considered in future roadmap discussions for the plugin.
Thanks always for your great work!
@Jiwoon-Kim WordPress itself does not support Markdown, so I see that as plugin territory. If there is an extension or alternative to the block editor, this plugin can/should also extend the Activity before it is federated.
If there is already a well known plugin, I am happy to support adding an integration: https://github.com/Automattic/wordpress-activitypub/tree/trunk/integration
Thanks for the clarification, @pfefferle! You’re right — technically WordPress core doesn’t have native Markdown support, but here’s what I’ve noticed and would like to suggest as a possible approach:
- When you copy AI-generated content (like from ChatGPT) and paste it into a text editor like Notepad, it preserves Markdown syntax.
- If you paste it into the WordPress Block Editor, it automatically converts Markdown-style content into appropriate blocks (like headings, lists, etc.). This means the Block Editor has some built-in Markdown parsing behavior.
- Additionally, using the Jetpack Markdown block, you can explicitly support Markdown syntax within posts.
Another observation: When viewing WordPress posts in Mastodon, they appear as Notes, but when embedding a Mastodon link in a WordPress post, it renders as an Article. This suggests that federated articles can technically retain their structure and formatting. https://travel-in-busan.com/topics/it/wp/wordpress-get-involved/
Also — on the frontend, when copying a WordPress post and pasting it using Windows PowerToys Advanced Paste, it can convert it to Markdown locally without AI involvement: https://learn.microsoft.com/en-us/windows/powertoys/advanced-paste
Rough idea: I think a practical way forward could be to leverage something like [Blocks Everywhere](https://wordpress.org/plugins/blocks-everywhere/) to store federated comments as blocks within WordPress. Then, for outbound federation, map Gutenberg blocks to Markdown-like structures when sending federated posts, and also support including content from Jetpack’s Markdown block where available.
It’s an idea still in draft form, but I believe it could help enhance interoperability with instances that partially or fully support Markdown.
Would love to hear your thoughts on whether this might fit into the plugin’s extension framework.
I’m not entirely sure, but according to [this post](https://developer.wordpress.org/news/2025/06/whats-new-for-developers-june-2025/):
Themes
New Blocks: Comments Count and Comments Link
The Comments Count and Comments Link blocks have long been available in the Gutenberg plugin under an experimental flag. They were two of the remaining blocks needed to achieve parity with PHP-based template tags for theme authors. As of Gutenberg 20.7, these two blocks are [no longer experimental](https://github.com/WordPress/gutenberg/pull/69832), and will be officially available in the next major WordPress release.
Would it be possible for the Comments Link block to serve as the URI for a federated Note? I’m wondering if this could be a natural way to link back to individual discussions within a federated context.
@pfefferle I believe implementing Polls as a block is indeed the right direction. As discussed in [issue #1791](https://github.com/Automattic/wordpress-activitypub/issues/1791), this approach would allow polls embedded in federated comments (notes) from platforms like Mastodon or Misskey to be rendered properly in WordPress via the Blocks Everywhere plugin.
This way, we could maintain consistency in displaying interactive elements like polls across federated instances and WordPress sites.
There is a project that works on a poll implementation based on blocks already: https://codeberg.org/linos/wordpress-polls-for-activitypub
@pfefferle Adopting GitHub’s comment editor instead of plain Markdown also seems like a good idea to me.
Honestly, rich text options are really only necessary for articles — there’s no need to overload comment notes with too many formatting features.
Could GitHub’s comment hiding UI be adapted for WordPress content warnings (CW)?
It might be a good idea to render previews in block format, since a federated reply could also include a boost-quote block.
Honestly, considering Markdown compatibility isn’t really that important as long as it gets converted to rich text when federated through the block editor. It could actually become a pretty blurry topic — since it’s about whether to load custom blocks as Markdown or not.
I might have overextended my explanation earlier — but to add some context:
Will polls be offered as a fully native feature in WordPress ActivityPub, or only integrated through an additional extension plugin? If polls are provided optionally via a third-party plugin, it creates a problem. A federated poll sent from one WordPress instance wouldn’t render properly on another WordPress instance unless both support the same implementation.
That’s exactly the issue I’m concerned about for things like GatherPress federation as well.
On the other hand, if you think about it — integrating federation at the core level could essentially create a WordPress-exclusive federation layer within the ecosystem.(like org, article etc)
Would love to hear your thoughts on whether this might be considered in future roadmap discussions for the plugin.
I don't think it's a priority at this time.
