Refactor comment system to handle ActivityPub interactions natively

[Jiwoon-Kim]

Why not just remove (or repurpose) the content field from the comments database table and use it to store interaction activities instead — like, announce, quote, follow, ping, or anonymous comments?
Then we could treat inReplyTo (whether local or remote) as a CPT reference linked through the posts field.

If you think about it, this seems like the cleanest way to integrate with the WordPress core structure.
On the frontend, we could use an inReplyTo block instead of the traditional comments block,
and simply pull like/repost counts and other metrics from the comments fields.

Proposed Solution

• Repurpose or extend the content field in the comments table to store serialized or URI-based interaction data.
• Treat inReplyTo (local or remote) as a reference to a Custom Post Type (CPT) linked via the post_ID field.
• This would allow the comment system to act as a universal interaction layer across both local and federated contexts.

Frontend Implementation Idea

• Replace or extend the current Comments Block with an inReplyTo Block.
• This block could dynamically render comment threads, likes, and reposts using data from the existing comments database structure.

Benefits

• Native integration with WordPress Core structure (no need for extra custom tables).
• Unified logic for handling all types of ActivityPub interactions.
• More extensible block-based frontend rendering.

---

For example:

• When the original post is deleted, all related comments are also deleted. This behavior is fine for traditional comments, but not suitable for ActivityPub interactions, which can and should persist independently of the original post.
• The content field in the comments table is redundant or unnecessary for many interaction types (e.g., Like, Announce, Follow).
• Integrating remote objects (inReplyTo) into the comment system becomes complicated.

Proposal:

• Remove (or repurpose) the content field in the comments database for ActivityPub-related interactions.
• Treat interactions as a separate CPT (custom post type) that stores inReplyTo (local or remote) as a reference.
• Use a dedicated CPT for ActivityPub objects instead of relying on comments.
• Frontend-wise, replace the comments block with an inReplyTo block, which can fetch and render interaction data such as Like and Repost counts.

This approach would integrate much more cleanly with the WordPress core structure, since CPTs already support REST, meta fields, and query handling. It would also simplify frontend management of remote ActivityPub objects.

[Jiwoon-Kim]

It seems there might have been a slight misunderstanding — this is still a rough idea.
Storing certain interactions like Follow in the comments table actually has some advantages.
For example, when a Delete actor activity occurs, removing all related Follow activities becomes very straightforward.

[Jiwoon-Kim]

The WP Comment structure is inherently dependent on its parent object, which actually makes it quite suitable for storing interaction activities.
This hierarchical relationship aligns well with how activities like likes, boosts, and follows reference another object as their target.

In the case of an Undo activity, it can be mapped to the deletion of a comment field, which makes it easier to distinguish from an actual object deletion.
This approach provides a clean way to handle reversible actions without interfering with the object’s existence itself.

[obenland]

#2311 represents a next step on this, using a CPT rather than comments to store that information.