Clarification on Idempotency for Specific Activity Types (Like, Announce, Follow)

[Jiwoon-Kim]

1. Clarification on Idempotency for Specific Activity Types (Like, Announce, Follow)

The ActivityPub specification and subsequent discussions have highlighted ambiguities regarding the idempotency of certain core activities, particularly in how they are stored, retrieved, and processed, which can lead to inter-server interoperability challenges.

This discussion aims to clarify the preferred behavior for the wordpress-activitypub plugin regarding activity idempotency.

Key Activities for Consideration

1. Like Activity:

   • Spec/Community Context: The AS2 inverse activities (Like and Dislike) are semantically distinct and do not inherently "undo" each other. However, most Fediverse implementations treat an actor's Like on a specific object as idempotent, meaning an actor can only have one active Like on a single object at a time. The liked collection is usually unique by object ID.
   • Question: Should the wordpress-activitypub plugin enforce idempotency for Like activities (one Like per actor per object, with a new Like replacing the old one, or simply being ignored if one exists), or should it allow multiple distinct Like activities (each with a unique id) as technically permitted by ActivityPub's simple collection model?

2. Announce Activity (Boost/Renote):

   • Spec/Community Context: The spec primer explicitly states that Announce activities are not idempotent, allowing for multiple announcements of the same object (e.g., reminding about an event). However, platforms like Mastodon enforce idempotency (one boost per post), while others like Misskey allow multiple "Renotes."
   • Quote/Republish: Since a Quote mechanism (e.g., a Create activity with a content and a context/inReplyTo pointing to the original post, or using the quote property which is not standard AP but widely used) effectively covers the use case of re-sharing with added commentary, I propose the following for pure Announce activities:
     • Proposal: Implement idempotency for Announce of non-event objects (e.g., Note, Article) for better compatibility with major Fediverse servers like Mastodon.
     • Exception: Allow non-idempotent Announce for objects where repetition is semantically meaningful (e.g., Event reminders), and also be prepared to receive and store non-idempotent Announce from other platforms (like Misskey's renotes) to maintain the integrity of the object's shares collection.

3. General Activity ID vs. Semantics:

   • The issue lies where an activity's unique id (making it technically non-duplicate in a Collection) conflicts with its semantic meaning (e.g., a user should only "like" a post once).
   • The spec suggests that Undo should target a specific activity id. If we enforce semantic idempotency for Like, an Undo should effectively target the single existing Like activity.

We welcome input from maintainers and the community on the chosen approach for the WordPress plugin to ensure broad interoperability while adhering to common user expectations.

---

2. Outbox Optimization: Deduplication and Display of Latest Object State

본문:

Problem

When an actor on a WordPress site publishes a post (via a Create activity) and subsequently edits it multiple times (generating several Update activities), the actor's Outbox currently exposes both the original Create activity and all subsequent Update activities.

This behavior has several potential issues:

1. Bloated Outbox: The Outbox contains redundant history, increasing the payload size and the number of items clients need to process.
2. Revision Exposure: It effectively exposes the revision history of the object, which might not be desirable for a public "activity stream" intended for consumption by followers (analogous to how a user's timeline usually only shows the latest version of a post).
3. Client Confusion: Clients consuming the Outbox may struggle to determine the single, current representation of the object without fetching the object's URI or applying complex logic to find the latest Update for a given object ID.

The ActivityPub specification states the Outbox "contains activities the user has published" and is a feed of "continued relevance," but does not explicitly forbid or mandate showing all updates. However, the spirit of a social media "feed" often suggests displaying the latest state.

Proposal: Outbox Deduplication and State Consolidation

To optimize the Outbox and align with common Fediverse user experience, we propose the following change in how the Outbox is constructed for an actor's core objects (e.g., Note, Article):

1. Prioritize Latest Activity: For any object that has been created and subsequently updated, the Outbox should prioritize showing only the most recent activity related to that object.

   • If the object has been edited, display the latest Update activity.
   • If no edits, display the original Create activity.
   • A subsequent Delete activity should, of course, be displayed as the latest state and potentially cause the object to be removed from the Outbox entirely (depending on implementation choice for deleted content).

2. Display Consolidated Object: Regardless of whether the Outbox entry is a Create or an Update activity, the embedded object should always reflect the current, latest state of the WordPress post/object (i.e., the state after all partial updates have been applied), as required for Server-to-Server Update delivery.

This approach effectively treats the Outbox as a deduplicated, chronological stream of the actor's current relevant activities, rather than a full revision log.

We request discussion on the technical implementation of this deduplication and its impact on clients consuming the Outbox.

(참고: 해당 제안은 WordPress의 revision 기능과 별개로, Outbox에 노출되는 활동의 목록 자체를 경량화하는 데 중점을 둡니다.)

[Jiwoon-Kim]

5.5 Inverse Activities and "Undo"
https://www.w3.org/TR/activitystreams-vocabulary/#inverse

Several of the core Activity types are defined as natural inversions of one another. These include:

Accept and Reject,
Arrive and Leave,
Join and Leave,
Create and Delete,
Like and Dislike

It is important to note that these types of activities are semantically distinct from one another and have no direct relationship on the other. That is, for example, if an actor "likes" a note at one point in time then later "dislikes" it, the "dislike" activity does not "undo" or negate out the prior "like".

The Undo activity type is defined to provide the specific ability to undo or cancel out a prior activity. The appropriate interpretation for the following, then, is that Sally liked John's note at one point but has explicitly redacted that like later on.

---

https://www.w3.org/wiki/ActivityPub/Primer/Referring_to_activities

• Like: Typically, an actor can only like one object one time. So, the actor id and object id should uniquely identify the Like activity. If there have been multiple Like/Undo Like pairs, the most recent Like is probably the one being referred to. In addition, the likes collection of the object should include at most one activity matching this actor id.
  • An exception applies for some systems which allow generating and sending multiple Likes of the same object. This is particularly the case when the Like activity has content included. In such a case, it is necessary to use the id of the specific Like you are trying to Undo.

w3c/activitypub#384
Undo activity without an ID on the object activity #384

I agree that publishers should include IDs for maximum interop, but also that consumers should try to handle ID-less activities. If both sides do some extra work, we can avoid interop failures.

---

w3c/activitypub#381
Tracking Issue: Should idempotency (or not) of certain activities be explicit? #381

is there any idempotency in processing activities, either from a C2S or S2S perspective? I have seen it proposed (albeit semi-unseriously) that you could send multiple Follow or Like activities in order to represent a “super follow” or a “super like”. The only explicitly idempotent bit is the side effect of adding the object to an unordered Collection, which is technically a set and therefore theoretically can’t contain duplicates. A more “common usage” interpretation would hold that follows and likes should be idempotent, but there’s nothing actually establishing this one way or the other. The most naive implementation of, say, C2S or S2S Like, is to handle each Like separately if each activity uses a different id. It then follows that you could post 10 likes of the same object and subsequently undo 3 of those specific activities. And for what it’s worth, adding each activity to either a Collection or an OrderedCollection will not be deduplicated, because each of those activities has a different id. You’ll effectively need to add an implementation quirk that tries to dedupe activities by their shape rather than by their id, in which case… of what purpose is the id? Why bother looking up the original id at all?

There's clearly a gap between AP's technical activity processing and the user-visible semantics. If you send two Likes of a given object, with two different ids, and then Undo one of them, AP may specify that the other one remains in the likes/liked collections. OK. But that may not match user expectations, ie if a user currently likes a post, and then they unlike it, they then no longer (visibly) like it.

reposts could be stateless, ie you could repost the same post multiple times

The hard part is that all activities can be considered a "post" -- there is no real concept of a "post" in the social media sense. A Like activity can be directly translated into a "John liked this" type of post, as seen on Facebook.

---

https://www.w3.org/wiki/ActivityPub/Primer/Like_activity

There is a "Dislike" activity in Activity Streams 2.0, but it is not used in ActivityPub.
An actor sending more than one Like activity for the same object is not discussed in the ActivityPub spec. However, most implementations treat the liked collection of the actor as unique by object id, and most implementations treat the likes collection of the object as unique by actor id.

https://seb.jambor.dev/posts/understanding-activitypub-part-2-lemmy/

Downvoting works similarly, but using a Dislike activity instead.

---

w3c/activitypub#386
Clarity on behaviour with multiple Announce activities for the same object #386
https://www.w3.org/wiki/ActivityPub/Primer/Announce_activity

Idempotence of Announce activities

Announce activities are not idempotent. It's possible to announce the same object multiple times. For example, re-sharing an Event object with the invitees to remind them of the upcoming event perhaps 1 week, 1 day, and 1 hour before the event.

However, some social network platforms, like Twitter, have idempotent sharing; for example, you can only retweet a tweet once (though you can share a tweet multiple times by quoting it).

---

https://docs.joinmastodon.org/spec/activitypub/#supported-activities-for-statuses
Announce
Transformed into a boost on a status

https://misskey-hub.net/en/docs/for-users/features/note/#renote
The act of quoting an existing note, sharing an existing note, or the note created as a result of these acts are all called Renote (or "renoting" as verb). Most of the time, this is used when you want to share a note you like to your own followers, or when you want a share a note that you posted in the past once more. While it is possible to renote the same note multiple times, please be aware that doing so may be seen as annoying by others.

In Mastodon, a post can be boosted only once, but in Misskey, a note can be renoted multiple times.

---

In my opinion, since a quote (which can be referenced multiple times) is already implemented, it’s reasonable for Announce activities to be idempotent.
However, Announce activities of Event objects should allow duplicate receptions, and Misskey’s repeated renotes should be receivable and stored individually.

[Jiwoon-Kim]

After giving it more thought, I think notifications for Event objects might be better implemented using RSVP as a form of Join activity, with local in-app notifications for RSVP responses — rather than federating Announce activities.

[Jiwoon-Kim]

https://www.w3.org/TR/activitypub/#update-activity-outbox

6.3 Update Activity

The Update activity is used when updating an already existing object. The side effect of this is that the object MUST be modified to reflect the new structure as defined in the update activity, assuming the actor has permission to update this object.

6.3.1 Partial Updates

For client to server interactions, updates are partial; rather than updating the document all at once, any key value pair supplied is used to replace the existing value with the new value. This only applies to the top-level fields of the updated object. A special exception is for when the value is the json null type; this means that this field should be removed from the server's representation of the object.

Note that this behavior is for client to server interaction where the client is posting to the server only. Server to server interaction and updates from the server to the client should contain the entire new representation of the object, after the partial update application has been applied. See the description of the Update activity for server to server interactions for more details.

https://www.w3.org/TR/activitypub/#update-activity-inbox

7.3 Update Activity

For server to server interactions, an Update activity means that the receiving server SHOULD update its copy of the object of the same id to the copy supplied in the Update activity. Unlike the client to server handling of the Update activity, this is not a partial update but a complete replacement of the object.

The receiving server MUST take care to be sure that the Update is authorized to modify its object. At minimum, this may be done by ensuring that the Update and its object are of same origin.

---

Since WordPress already has a built-in revision system, I believe implementing Partial Updates would be relatively easy.

However, one thing I found curious is that when inspecting the outbox, I noticed both Create and Update activities being published.
Is this really necessary?
It feels somewhat like exposing the internal revision history rather than just reflecting the current state of the object.

https://mastodon.social/statuses_cleanup