Pre-FEP: Reassigning Actor and CoAuthor Representation for Federated CMS

jiwoon · October 22, 2025, 4:30pm

(draft) Pre FEP-XXXX: Reassigning Actor and CoAuthor Representation for Federated CMS · Automattic/wordpress-activitypub · Discussion #2358

Topic: “Ownership Transfer Activity (Introduction of 4th and 5th sentence structures)”

Context

https://github.com/Automattic/wordpress-activitypub/issues/2353
Post Author and Object Actor Synchronization Issue

Introduction

I tend to understand the ActivityPub protocol by analogy with English grammar, for example, mapping intransitiveActivity to the 1st form S+V.

we need to explore whether there’s a way to change an object’s actor.

When a media owner changes, it seems natural to apply English grammar 4th form S+V+I.O+D.O,
and when the post author changes, to apply English grammar 5th form S+V+O+O.C.
Personally, I think this is the most intuitive approach, but since a FEP proposal is required, I think it is worth discussing whether it can be handled with legacy approaches.
In any case, in a CMS, changing the author is a core function, and WordPress is a platform directly affected, so it should be possible to represent this in the ActivityPub protocol.

Also, for example, cases like changing the license owner of an image object whose license attribute is extended will certainly occur, so the fundamental action of changing an object’s actor can occur universally.
However, ownership transfer for objects like document, page, image, video, audio can be implemented as a Move activity between object collections via the mediaUpload endpoint, but for objects like article or note, they are handled via the outbox → activity collection, so there is a slight difference.

Mapping Activities to English Grammar Structures

Mapping ActivityPub Activities to English sentence structures (grammatical forms) is
very effective for visually understanding the semantic structure of the protocol.
The ActivityPub “activity model” essentially borrows the structure of a “language model (grammar).”
ActivityStreams can be considered a kind of “behavioral sentence system.”

It could even evolve into a meta-standard document like “Activity Grammar.”

English Grammar Mapping Summary

1st Form (S + V) — IntransitiveActivity

https://www.w3.org/TR/activitystreams-vocabulary/#dfn-arrive

IntransitiveActivity — activities without an object
Example: Like, Follow, Arrive, Leave, Join, Travel
→ Actor performs an action without a direct object.
→ Example: Alice Followed. (focus on state change)
→ Subject (Actor) and verb (Activity) exist, but there is no object (Object).

Grammatically, this is a complete sentence, but it is an action that does not require a target.
This aligns exactly with ActivityPub’s definition of intransitiveActivity.

“Indicates that the activity does not have an object.”

2nd Form (S + V + C) — State Change Type (e.g., Update)

https://www.w3.org/TR/activitystreams-vocabulary/#dfn-update

State Descriptive (e.g., Be, Become, Seem)
This is similar to an activity like Update that expresses a property change (state change).
→ Example: Alice Updated (is now editor of) Note.

Here, the object functions like a complement, describing the result of the subject’s action.
Grammatically, Update expresses the state change via a complement.

3rd Form (S + V + O) — Transitive Activity

https://www.w3.org/TR/activitystreams-vocabulary/#dfn-create

Activities like Create, Delete, Follow, Block, Announce, Add, Remove are typical 3rd form.

TransitiveActivity — action with a single object
Example: Like, Announce, Create
→ Example: Alice Created Note.

4th Form (S + V + I.O + D.O) — Double Object Activity

https://www.w3.org/TR/activitystreams-vocabulary/#dfn-offer

ActivityPub standard does not explicitly define an indirect object (I.O) structure. However, target or origin fields can serve the role of an indirect recipient.

Double Object Activity — includes both recipient and object
Example: Give, Offer, Send, Add, Move
→ Example: Alice Moved Note from Outbox to CoAuthorOutbox.
→ Example: Alice Added Object to Target.

This is similar to English 4th form.
In other words, object (direct object) + target (indirect object).

This form structurally matches “Actor reassignment” — the action of “transferring” a post (Direct Object) to another actor (Indirect Object).

Media Objects

Objects like image, video, audio
can be handled via collection-to-collection move (Move) through the mediaUpload endpoint.

“Changing media ownership corresponds grammatically to a 4th form verb structure (S+V+I.O+D.O) and can be represented in ActivityStreams via Move/Add activities.”

However, for Note, Article, etc., which are delivered directly via outbox → activity,
the difference is that it requires republishing under a new actor rather than simple movement.

Summary

“Changing post author” corresponds grammatically to 5th form verb structure (S+V+O+O.C).
In CMS, changing author_id is a natural operation, so it should be expressible in ActivityPub.
Most platforms currently assume immutable authors, so FEP-level extension is needed.
This lays the foundation for co-author or collaborative post (CoCreate) scenarios.

This grammar mapping model can also be visualized as a diagram of ActivityPub Sentence Grammar Model (SVO, SVOO, SVOOC), showing how activities like Create, Announce, Move, Reattribute correspond to sentence structures.

Situation	Grammar Correspondence	Activity Example	Note
Simple action (arrive, leave)	1st Form	`Arrive`, `Leave`	IntransitiveActivity
State change	2nd Form	`Update`	object state change
Create/Delete/Follow	3rd Form	`Create`, `Delete`, `Follow`	Transitive verb type
Ownership/Author change	4th Form	`Transfer`, `Assign`, `Offer`	FEP proposal needed
Media move	Mixed 3rd~4th Form	`Move`	collection transfer

Grammar Approach for “Actor Change”

When a media owner changes, a ditransitive verb structure (S + V + I.O + D.O) is more appropriate.
Example: “Jiwoon transferred ownership of the image to Mogu.”

{
  "type": "Transfer",
  "actor": "https://example.com/@jiwoon",
  "object": "https://travel-in-busan.com/post/1",
  "target": "https://example.com/@mogu"
}

→ Conceptual extension like “TransferActivity” is required.
This is a case that can be proposed in a FEP.
(Example: if Move is collection-to-collection movement, Transfer is defined to mean ownership change.)

The 5th form (S+V+O+OC or S+V+O+O.C) approach is effective for structurally expressing actor change.

ActivityPub Structures Viewed via English Grammar

Sentence Form	Grammar Structure	ActivityPub Correspondence	Example
1st Form	S + V	`IntransitiveActivity`	`Like`, `Arrive`, `Travel`
2nd Form	S + V + C	State descriptive `Update`, `Announce`	“Post is public”
3rd Form	S + V + O	Common `Create`, `Delete`	“User creates Post”
4th Form	S + V + I.O + D.O	Ditransitive (two targets)	“Admin assigns Post to Author”
5th Form	S + V + O + O.C	Changes object state	“Admin makes Post belong to Mogu”

1. Current discussion: Author change = 5th form

Example:

“Jiwoon (S) → reattributes (V) → Post (O) → to Mogu (OC)”

This is a typical 5th form SVOOC sentence.
Meaning structure: the subject changes the property (owner) of the object.

ActivityPub equivalent:

{
  "type": "Reattribute",
  "actor": "https://example.com/@jiwoon",
  "object": "https://example.com/@post123",
  "target": "https://example.com/@mogu"
}

This almost exactly matches the English 5th form make + O + OC structure.

actor: subject of verb (S)
type: verb (V)
object: action target (O)
target or resultingActor: new state/property (OC)

2. Why 5th form — emphasizes semantic change

4th form (S+V+IO+DO) is a transfer (“give something to someone”),
5th form (S+V+O+OC) is an attribute change (“make something become a state”).

Changing an actor is not just “give the post to someone else”;
it is an act of changing the ontological property of the post:

“The post’s owner (Actor) is now a different subject.”

→ This is not a simple move; it is an object’s identity transformation.
Hence, 5th form is more accurate.

3. Protocol Correspondence Proposal (FEP Perspective)

Grammar	ActivityPub Example	Description
3rd Form	`Create(Post)`	Object creation
4th Form	`Assign(Post, Author)`	Assign object to someone
5th Form	`Reattribute(Post, newActor)`	Change object’s actor

→ New activity types like Reattribute or ReassignActor best reflect the 5th form structure.

Example FEP draft:

{
  "type": "Reattribute",
  "actor": "https://example.com/@admin",
  "object": "https://example.com/@oldpost",
  "result": {
    "attributedTo": "https://example.com/@newauthor"
  }
}

4. Additional Semantic Advantages

Comparison	4th Form (Assign)	5th Form (Reattribute)
Actor	giver	modifier
Target	recipient-focused	object/state-focused
Focus	ownership transfer	identity change
Suitable Example	“transfer a file”	“make a post belong to another”

Thus, 4th form aligns with Move, 5th form aligns with Update/Reassign.
The “fundamental action of changing an object’s actor” clearly falls under the latter.

5. Conclusion — Insights from 5th Form Model

Mapping ActivityPub activities to grammar forms clarifies the semantic role labeling.
Actor change is a state mutation, making 5th form (S+V+O+OC) the most appropriate.
This perspective is persuasive when proposing a FEP.
Example:

“This proposal models actor reattribution as a fifth-form (SVOOC) structure, where the activity explicitly causes a change in the object’s ownership attribute.”

Realistic Problem

Most federated platforms (Mastodon, Misskey, Pixelfed, etc.)
do not support author change (Actor reassignment).

But in CMS Context

author_id can be changed in the database, and
WordPress allows change via REST API PUT/PATCH.
→ If ActivityPub assumes “immutable authorship,” it conflicts with CMS behavior.

CMS Perspective Reality

In CMS (especially WordPress), changing post_author is a core function.
In ActivityPub, author = actor when serialized, so
an activity is needed to update the object’s actor.
This is closer to ownership transfer than a simple Update.

Hence, a two-step approach can be proposed:

Propose Transfer or Assign Activity (specifiable in FEP)
Temporarily represent via changing attributedTo in existing Update Activity (legacy-compatible)

Proposed Directions

Short-term (legacy compatibility)
- Extend Update Activity to include actor change (non-standard)
- Use array in attributedTo to implement “co-author” concept
Mid-term (standard discussion)
- FEP proposal: “Reassignment Activity” or CMS-specific subclass of Move
- Example: MoveAuthorActivity or TransferAuthorship
Long-term (Fediverse-wide extension)
- Like Instagram “collaborative posts” or YouTube “co-upload”
  propose CoCreate activity (as you mentioned)
- actor: [main author], attributedTo: [co-authors], context: [shared collection]

Related Links

ActivityPub immutable actor attribution?
https://socialhub.activitypub.rocks/t/delete-actor-behavior/573
https://socialhub.activitypub.rocks/t/are-actors-and-webfingers-1-to-1/4539
https://fedify.dev/manual/actor
https://www.w3.org/wiki/ActivityPub/Primer/Authentication_Authorization#Object_ownership

In fact, this is one of the most interesting limitations of ActivityPub —
within the standard Vocabulary, there is no Activity type that directly corresponds to the typical ditransitive (S+V+O+OC) structure.

Assign (informal, used in some FEP/ForgeFed contexts)
“Admin makes Post (be authored by Jiwoon)” —
In other words, a combination of Assign + Update is effectively the closest approximation to a ditransitive structure.

Move
Meaning: “Moves an object from one collection (origin) to another collection (target).”

Grammatical correspondence: S + V + O + OC

Example: “System moves Post (to target collection)”

Structurally, it resembles a ditransitive construction, but semantically it is closer to spatial relocation.

While it is similar in the sense of “changing membership,” it is distinct from “changing an attribute (Actor).”

Accept / Reject / Add / Remove

These four all partially exhibit a ditransitive-like structure in that:

“An object is included in or removed from a collection.”

silverpill · October 22, 2025, 9:14pm

The change of author (owner) is technically very similar to the migration of a post from one server to another. Have you seen FEP-1580, proposed by @jonny?

Co-authorship is a different issue. I think attributedTo should always be a single actor because it has special meaning (more about ownership here: FEP-fe34). Co-authors could be specified using another property to avoid confusion.

trwnh · October 30, 2025, 4:17am

in theory, no, nothing is immutable, although the id generally should not change. this id is assigned to activities when they are POSTed to the outbox. the body content of the POST request is used as input to generate a similar activity that has the assigned id.

but of course, as you note, popular federated platforms make all manner of assumptions based on their platform’s internal model. multiple attribution and changing attribution should be possible in a general sense, but is not possible due to being unsupported by softwares that make incompatible assumptions.

for a non-activity object, it seems relatively less controversial to update the object (Update activity, HTTP PUT/PATCH, etc) to have a different value for attributedTo, although one objection is that, in a social setting, it could be inappropriate to give something to someone without their consent. verifying this consent is necessary if we want to talk about “ownership” in a social sense. the problem is that attributedTo bundles too many concerns that should be separate – it is used not only for authorship, but also ownership, with no distinction between authorship and ownership.

one approach that could work is to use a different property for authorship, like dc:author or dcterms:author. another approach is to instead split out ownership into a separate property, or otherwise apply a model of ownership derived from the id instead of from attributedTo (for example, saying https: resources are owned by the authority component which is the web origin), or have ownership inferred from being part of some base container. but these approaches still require your peers to share the same understanding as you, and the concept of ownership is kind of fuzzy. more concretely, things like the Security Vocabulary have deprecated the concept of an “owner” in favor of the concept of a “controller”.

for activities, you have the same issue, but there is an additional issue with some platforms not actually caring about activities, so they don’t expect to receive an Update whose object is an Activity, and they wouldn’t know how to handle that. alternatively, other platforms might want to treat activities as part of an immutable event stream.

i think before developing a vocabulary to describe assignments and transfers, it is important to first figure out the more fundamental question of control, and specifically to reach an agreement on this question with your peers: who should have it? from where does the authority for an identifier derive? how can you trust statements about (rel, link relation) or referring to (rev, reverse relation) that identifier? this isn’t an aspect of “cms perspective” as much as it is an aspect of how identity is constructed and negotiated within a distributed system.

jiwoon · November 3, 2025, 10:20am

ActivityPub/Primer/Authentication Authorization - W3C Wiki

Object ownership

Activities that create or modify an object - Create, Update, Delete, Undo, Move, etc - must be the same actor as the original object’s attributedTo or activity’s actor. This is generally called the “same origin policy.”

silverpill · November 3, 2025, 2:35pm

No one calls this same origin policy
It is same actor / same owner.