Database Extensions for Federation Support and Compatibility at the WordPress Core Level

[Jiwoon-Kim]

https://core.trac.wordpress.org/ticket/63966

The extension of the ActivityPub protocol in WordPress is currently being developed not by the community but under the leadership of Automattic. However, this is only because the current implementation has not yet matured enough to be directly integrated into the Core. This does not mean that the Core team can simply ignore the issue.

Of course, I should not state it too definitively, but personally I am convinced that in the future it will inevitably be integrated into WordPress Core. Therefore, even if this issue is not yet being directly addressed at the global community level, I would like to raise it as something that should be considered.

• https://wordpress.org/plugins/activitypub/
• https://wordpress.com/support/enter-the-fediverse/fediverse-blocks/
• https://wordpress.com/blog/2023/10/11/activitypub/
• https://www.theverge.com/2023/10/11/23913278/wordpress-activitypub-official-plugin-automattic-fediverse-mastodon

For these reasons, I believe it is important to raise compatibility concerns on Trac as well. If the philosophical gap between WordPress Core logic and the ActivityPub protocol grows larger, it will become increasingly difficult to align them in the future.

And I do not think this is unrelated to improving the structure of Core itself. If WordPress evolves toward a more modern and interoperable structure, future integration will be smoother and WordPress will avoid drifting into a “Galápagos” model that ignores broader web standards.

The reason I am raising this issue is that (if I remember correctly) the ActivityPub plugin prioritizes integration with the existing structure and does not add separate database tables, so that it can be cleanly removed if needed.

Simply put, the ActivityPub vocabulary has actor, activity, and object. Actors can be understood as WordPress authors, and objects as WordPress posts or media.
On the other hand, activities (likes, reposts, follows, etc.) are handled in a way similar to WordPress.com Reader Notifications.
Does Core DB have a table to handle notifications? No, it does not. Isn’t that why notifications are implemented by mass-sending emails?
Why can’t self-hosted WordPress receive in-app notifications via PWA? Why must it always be connected to Jetpack or flood users with email notifications?

Why, when we visit another WordPress blog and leave a comment, do we have to enter our name, email, and URL as “anonymous”? Why must impersonation and spam be tolerated?
Why can’t we “follow” another site from “My Site” or compose a comment on my site and have it “sent” directly to a post on another site?

In conclusion, it seems inevitable that ActivityPub integration into Core will eventually happen. Currently, there is no table in Core to handle activities (which is why they are being stored in comments, but that is actually incorrect). What is needed is not only a local profile but also a remote actor table capable of handling proxy profiles, and a remote object table to subscribe to and “repost” those actors.

However, such tables may not be strictly necessary in the existing Core, and since the ActivityPub plugin does not add new tables, a situation has arisen where responsibility is shifted back and forth. If the integration of the ActivityPub protocol into WordPress Core is to be seriously considered, then even if the operational logic is implemented by the plugin, the database tables themselves should be implemented at the Core level. That is my conclusion.

---

Four Key Points

1. Current Reality

   • The ActivityPub plugin is currently developed by Automattic as a third-party project.
   • It avoids creating new DB tables and instead forces mapping onto the existing comments structure.
   • This was intentional, to ensure removability and compatibility with existing structures.

2. Problem Statement

   • The ActivityPub object model (actor, object, activity) does not map 1:1 to the WordPress DB schema.
   • In particular, activities (likes, follows, reposts, notifications) have no corresponding table in Core.
     → The lack of a notifications table means Core still relies on bulk email delivery.
   • As federation grows, this creates a “responsibility gap” between Core and the plugin.

3. Philosophical Concern

   • If Core remains indifferent, the gap between WP’s comment structure and federated replies will widen.
   • Later, when Core integration is attempted, “Galápagos-style” divergence could make compatibility or refactoring impossible.
   • Core needs to evolve toward a more modern and interoperable DB schema.

4. Conclusion & Proposal

   • ActivityPub integration into Core is, in the long term, virtually inevitable.
   • Even if plugin logic handles the functionality, Core should provide base DB tables (actors, activities, objects, notifications).
   • This ensures federation standards can be adopted, without pushing all responsibility to plugins.

---

For Trac

Since Trac focuses on specific bug/ticket-level issues, the higher-level schema discussion should eventually be raised as a Core proposal or dev note. If you open a Trac ticket, keep it concise, for example:

• “The current ActivityPub plugin avoids extending the DB schema, but long-term federation support will require Core-level DB tables for compatibility.”
• “Core currently lacks tables for concepts like Notifications and Activities. At minimum, schema design discussions are needed to ensure future interoperability.”

[Jiwoon-Kim]

At this time (and possibly forever), the ActivityPub standard still feels like plugin territory.

Additionally, the bar for adding new database tables is very high, especially when the flexibility exists in the current Database to support functionality. As Automattic's plugin seems to function without the need for new tables, the bar does not seem to be met that new tables should be considered. As such, I think this can be closed as maybelater.

If we cannot add new database tables, shouldn’t we consider treating all ActivityPub entities—actor, activity, and object—as objects and store them in the wp_posts table?

The moment the WordPress Core team argues that “adding DB tables is too difficult,” there are really only two options left:

1. Force-mapping all ActivityPub entities (actor, activity, object) into the existing WP schema

   • wp_posts → store almost everything as posts (e.g. actor, activity, and object as different post_types)
   • wp_comments → map replies and some activity
   • wp_users → only for local actors (remote actors don’t fit here at all)

   👉 This is the traditional WordPress way. bbPress, WooCommerce, EDD, and Jetpack all stuffed new concepts into post_type, comment_type, and meta in similar ways.

2. Separate tables are really needed, but Core doesn’t want them → plugins fake it

   • This is essentially what Automattic’s ActivityPub plugin does today.
   • But in the long run, this leads to structural mismatches (the ActivityPub model of actor/activity/object conflicts with WordPress’s post/comment model).

---

🔍 The issue is that your suggestion—treating actor, activity, and object all as objects inside wp_posts—actually aligns better with the Core philosophy.

• post_type = actor
• post_type = activity
• post_type = object

This way, we don’t need to expand the DB schema while still being able to represent federation entities.
But it also creates some awkward mismatches for both ActivityPub and WordPress Core:

• actor = a person/profile, but treated like a post with a slug/permalink
• activity = an event (like, follow, boost), but stored like a post that supports revisions/taxonomies
• object = posts/media fit naturally, but federated objects can overlap with local canonical objects

---

📌 To summarize:

• If Core refuses new tables, then yes, normalizing actor/activity/object into wp_posts as different post_types may be the most consistent fallback.
• But this is risky if not coordinated at the Core level, since overloading the DB schema could have serious performance and maintainability costs.

---

So the real questions for Core devs are:

• “If we cannot extend the DB, should we normalize ActivityPub’s actor, activity, and object into wp_posts as different post_types?”
• “Wouldn’t this be more consistent than splitting them inconsistently across posts, comments, and meta?”