Re: Activities as Activity objects is sometime confusing

ne 19. 4. 2026 v 15:36 odesílatel Cristiano Longo <
cristianolongo@opendatahacklab.org> napsal:

> In some cases, having Activities as objects of other activities is
> confusing me. Here follows some examples. Le us consider an object O
> created by an activity C, an such that some user liked O. What happens
> if the activity C is created? How to handle that C may be updated by a
> subsequent activity U which changes C in order to not mention O?
>
> A bit more complex example where the create activity C1 created another
> activity C0 happened in the past.
>
> {
>    "@context": "https://www.w3.org/ns/activitystreams",
>    "id": "C1",
>    "type": "Create",
>    "endTime": "2026-04-09",
>    "actor": "p",
>    "object": {
>      "id": "C0",
>      "type": "Create",
>      "endTime": "2026-04-08",
>      "object": {
>        "type": "Note",
>        "name": "A Simple Note",
>        "content": "This is a simple note"
>     }
>    }
> }
>


Hi Cristiano,

Your confusion is justified. This is an example of idea drift leading to a
leaky abstraction. When AS was created it was about Activities e.g. "Alice
liked your post", similar to a notification dashboard.

Activity Streams 2.0 uses activities *descriptively* (a "Create" reports
that something happened).

ActivityPub uses the same verb *performatively* (a "Create" delivered to an
inbox asks you to make it happen).

That’s why cases like "C1 Create C0" are ambiguous. It reads as a
description of a past activity, but looks identical to an instruction.

Similarly:

- Editing C changes the record, not the object O
- Likes attach to O’s id, so they survive
- Removing O requires Delete O, not rewriting C

Delivery implies performative, embedding or retrieval implies descriptive.
Not specified, but that's how implementations evolved.

As the social web grows and specs evolve, a clearer separation between
activities and content objects could reduce this ambiguity.

Best,
Melvin