On using context for taxonomy and contextHistory for comments and threads

[Jiwoon-Kim]

I closed the issue and moved the content into Discussions.
This is in the same line as my earlier ideas, but since there are FEP references available now, I thought it was worth revisiting.

Honestly, I’ve opened so many issues that even I have trouble remembering them all, and tracking the evolution of my own ideas has been difficult.

---

I believe it would be more appropriate to use the context property for taxonomy-related structures (categories, series, page ordering, etc.), while reserving the contextHistory property for conversations and threads.

---

Separation of replies and context

https://codeberg.org/fediverse/fep/src/branch/main/fep/b2b8/fep-b2b8.md#replies

Comments on the text should be linked in the replies property. This should be a URL that resolves to a collection of objects for the replies.
Comments are usually Note objects, but can be other types of objects like Article or Question.
This property provides the same functionality as the comments property in RSS 2.0.

https://codeberg.org/fediverse/fep/src/branch/main/fep/f228/fep-f228.md#contexthistory-property
FEP-171b: Conversation Containers
https://codeberg.org/fediverse/fep/src/branch/main/fep/171b/fep-171b.md#top-level-post

The author of a top-level post is not necessarily the conversation owner. When owner is a group, conversations can be started by any of its members.
The top-level post MUST have a contextHistory property that refers to the conversation container. The presence of this property indicates that publisher implements conversation containers.

Note: In addition to contextHistory property, implementers MAY add a context property that refers to a collection of posts.

WordPress has adopted FEP-f228: Backfilling conversations, but in my view, when context is used for taxonomy, contextHistory is a better fit for conversation threads.

---

Effective approach

• context for taxonomy: According to FEP-b2b8, context should represent larger collections like a blog category, a series, or a newspaper column.
• contextHistory for threads: For posts that belong to a conversation, contextHistory should point to the top-level post or conversation container. This represents the ancestry of the thread.

https://codeberg.org/fediverse/fep/src/branch/main/fep/b2b8/fep-b2b8.md#context

If the text is part of a larger collection, the context property can provide a link to the collection.
An example might be an article in a series, a newspaper column, a blog category (although tag may be better here) or a section of a magazine.

There can be multiple context properties, either as an array of strings or objects or both.

https://codeberg.org/fediverse/fep/src/branch/main/fep/11dd/fep-11dd.md#context-ownership

A context MUST have an owner. Actions carried out pertaining to the context itself MUST be carried out (via actor) by the context owner.

• Blog categories or page sequences → context owned by an Organization actor.
• Article series → context owned by a Person actor.

This distinction allows blogs to behave more like news or magazine publishers in the Fediverse.

---

On blog profiles and actor types

I don’t think it is appropriate for blog profiles to be modeled as Group actors.

While WordPress supports multiple authors, treating a blog profile as a group actor creates conflicts:

• Group actors typically aggregate or repost member activities.
• If a blog profile is a group actor, federated comments could be reposted as blog posts, which is misleading.
• This makes the blog behave like a forum, rather than a publisher (news/magazine model).

Even with FEP-1b12 (Group federation), the group actor model doesn’t align with how blogs function.
Instead:

• Blog profile → Organization or Service actor
• Individual posts → published by Person actors

This respects WordPress’s permission-based publishing model.

---

Inline images and attachments

All inline images in an Article should also appear in attachments.
FEP-b2b8: Long-form Text
https://codeberg.org/fediverse/fep/src/branch/main/fep/b2b8/fep-b2b8.md#content

Any embedded media like images, video or audio in the content property should also be listed in the attachment property so that consumers can pre-fetch the media.

FEP-1311: Media Attachments introduces the concept of multiple media versions and licensing.
https://codeberg.org/fediverse/fep/src/branch/main/fep/1311/fep-1311.md#multiple-media-versions

FEP-e232: Object Links
https://codeberg.org/fediverse/fep/src/branch/main/fep/e232/fep-e232.md
This could be useful for inline images as object links.

Issue with WordPress:

• Single inline images are less common than galleries.
• The gallery block often includes multiple media versions in the content itself.
• A simple inline-image model is insufficient.
• A more flexible approach may resemble FEP-c16b (Formatting MFM functions).

---

Multiple media versions

For heavy photologs (up to 50 images per post), embedding all versions in the Article object is inefficient.

• Articles should reference an attachment container URI (e.g., improved attachment_id permalinks).
• The container provides access to all media versions.
• The attachment property should only include the representative URI + main URL.
• UploadMedia endpoint can be used to handle version arrays more efficiently.

Related core proposal:
https://core.trac.wordpress.org/ticket/63953
Improving the Permalink Structure for ?attachment_id=123

---

Conclusion

Even if other Fediverse platforms lag in supporting long-form content and inline images, WordPress—being primarily a long-form platform—should take a proactive role in implementing FEPs.

By clearly separating context (taxonomy) and contextHistory (conversations), aligning blog profiles with Organization/Service actors rather than groups, and addressing inline media with scalable attachment strategies, WordPress can become a strong reference implementation for long-form ActivityPub.

---

Honestly, I understand the convenience of modeling WordPress blog profiles as Group actors, since WordPress is fundamentally a multi-author system.

Nevertheless, I don’t think it’s appropriate to model the blog profile itself as a Group actor. A blog should federate only posts — not comments or federated reply posts.

The multi-forum model, in my view, should instead be solved through bbPress compatibility, rather than redefining the blog profile actor type.

Even if we consider FEP-1b12 (Group federation), the group-actor approach does not align with how blogs function. A blog is not a forum where anyone can author posts—it’s closer to a magazine or newspaper.

---

In my opinion, by using the contextHistory property, it should be possible to store Delete activities, which could allow implementing placeholders for deleted comments.

I understand that it’s difficult to improve the actor model right now since there is no precedent for implementing an organization actor. Please just consider using the contextHistory property for now.