[wp-trac] [WordPress Trac] #63966: Database Extensions for Federation Support and Compatibility at the WordPress Core Level

[WordPress Trac]

#63966: Database Extensions for Federation Support and Compatibility at the
WordPress Core Level
-----------------------------+-----------------------------
 Reporter:  kimjiwoon        |      Owner:  (none)
     Type:  feature request  |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Database         |    Version:
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+-----------------------------
 ### 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.”

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63966>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform