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

[kimjiwoon]

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

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](​https://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.”

[jorbin]

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.