Re: Activities as Activity objects is sometime confusing

ne 19. 4. 2026 v 21:36 odesílatel a <a@trwnh.com> napsal:

> Melvin,
>
> > Activity Streams 2.0 uses activities *descriptively* [...] ActivityPub
> uses the same verb *performatively* [...] Delivery implies performative,
> embedding or retrieval implies descriptive. Not specified, but that's how
> implementations evolved [...] a clearer separation between activities and
> content objects could reduce this ambiguity.
>
> This is something that has been raised/discussed before as well, actually!
>
> Bumblefudge quotes me in https://github.com/w3c/activitypub/issues/381
> regarding a tangent wherein I discuss the assumed idempotency of Like
> or Follow activities. In the ensuing discussion, I say that activities
> *are* content -- we just have "side effects" attached to them. I don't
> think it's strictly about delivery vs retrieval/embedding, because
> implementations will often not make this distinction, and retrieving
> an object is treated equivalently as if a Create had been delivered
> (even if no such Create was ever delivered). Fast forward about 2
> years, and there is a proposal by me in
> https://github.com/w3c/activitypub/issues/510 (from some months
> earlier on the mailing list) regarding the negotiation of protocols
> and constraints for actors and clients submitting activities to
> inboxes and outboxes.
>
> In the sense that activities are content, we *could* describe the
> lifecycle of that content using Create/Update/Delete activities, but
> we generally don't, because it might not be relevant or interesting.
> Yes, submitting a Create activity to your outbox does result in a
> Create activity being published. You could even say that the Create
> activity was "created" in your outbox. But is that a useful thing to
> describe? Probably not. If we want to talk about how you "created" the
> Create activity, then we generally leave that up to the HTTP POST
> instead -- and we tend to treat HTTP POST as ephemeral, although we
> could log it, and we could further describe it.
>
> This isn't to say that activities can never be or should never be
> objects of other activities. In certain situations, with certain
> protocols, it can make sense. For example, https://w3id.org/fep/1b12
> as written by nutomic (Lemmy's author) describes their use of Announce
> activities to "share" other activities. (The same activities could be
> forwarded from inbox instead, but the Announce mechanism could enable
> adding such activities to the as:shares collection.) Or perhaps more
> illustratively, we can say that someone publishes an Arrive activity
> to describe visiting a certain Place, and then someone else responds
> with a Like activity. In a different case, you could perhaps confuse
> Liking an Article versus Liking that you Created the Article, but in
> this case, there is no other "content object" separate from the Arrive
> activity. Liking the Arrive is more clearly different than Liking the
> Place.
>
> Of course, other content models don't generally have "side effects" or
> behaviors associated with them. When you publish an atom:entry to an
> atom:feed, the only thing that happens is that the atom:entry now
> exists in the atom:feed. If ActivityPub's outbox was limited to simply
> publishing activities, then the outbox would be a sort of "feed"
> similar to Atom, except that every "entry" is specifically an
> Activity, and we could view the outbox as a sort of Activity Stream,
> if you will. This is not too foreign a concept, as Activity Streams
> originally evolved from an extension to Atom feeds, so the content
> model of an "activity" was composed with the content model of an
> "entry".
>
> Once you add those "side effects", the content isn't merely content
> anymore; it is now a procedure or method. How to separate these two
> aspects of "the same thing" is the subject of much discussion.
>
> An idea that was floated in a discussion with me and silverpill
> (Mitra's author) was to explicitly describe such "side effects" using
> the as:result property. Later, silverpill wrote
> https://w3id.org/fep/fc48 to describe an approach where
> Create/Update/Delete/Add/Remove activities are processed according to
> ActivityPub's "side effects" if they are described in the as:result
> property, so that any activity (including extension activities) could
> describe their "side effects" explicitly and no ahead-of-time
> understanding is needed of what an Activity should do. That way, a
> "generic side effect processor" could see that you Frobbed a Gantz and
> still recognize that it should add the Frob's actor to a collection
> maintained by the Gantz's author. I'm not sure this is the best
> formulation of the idea, but it does at least separate the "side
> effects" from the "content". If I had to workshop this idea a bit, I'd
> say that instead of as:result, it should be a different property like
> "sideEffects" that the outbox could listen for and attempt to carry
> out. (I guess certain activities end up effectively repeating
> themselves as side effects of themselves, but this isn't necessarily
> an issue.)
>
> Another idea I haven't written up anywhere else yet is to rely more on
> the natural "side effects" of HTTP POST by taking an activity and
> POSTing to a "collection endpoint" similar to the outbox, but
> dedicated entirely to tracking activities submitted to that endpoint.
> You could imagine the as:likes or as:shares collections operating like
> this, by POSTing a Like activity to your outbox, and then the outbox
> could POST it to the as:likes collection of the as:object. Or you
> could do a "private like" by POSTing it to the as:likes collection,
> but not to your own outbox. Or using the outbox delivery algorithm,
> you could address the likes collection and have the activity delivered
> via POST to its inbox (which may be the likes collection itself). It's
> not an entirely new idea, because in
> https://www.rfc-editor.org/rfc/rfc5023.html#section-9.2 you can see
> AtomPub using HTTP POST in the same way. And in fact, another version
> of the same idea made its way to WebDAV in
> https://datatracker.ietf.org/doc/html/rfc5995 -- so "POST to
> collection" is an idea that has come up at least 3 times.
>
> ---
>
> To directly answer Cristiano's questions, though:
>
> > What happens if the activity C is created?
>
> Per ActivityPub, if you submit C1 whose object is C0 to the outbox,
> then the outbox handler is currently specified to ignore the id of C0
> and to generate a new activity using the same input material, but
> assigned a different id (which will be returned with a 201 Created
> whose Location refers to that new id).
>
> > How to handle that C may be updated by a subsequent activity U which
> changes C in order to not mention O?
>
> If you assume activities are not immutable and that the outbox is not
> an append-only log or activity/event stream, then U would update C's
> resource's body content, and nothing would happen to O. (We already
> have a disconnect between the input material submitted for an Update
> via the outbox, compared to what eventually gets published. Recall
> that C2S Update is "partial", while S2S Update is "full".)
>

Thanks, helpful perspective, the content vs side effects framing clarifies
the issue nicely.