Section 6.3.1 C2S Partial Update property deletion behavior is impossible and should be deprecated

[trwnh]

#396 was closed without resolution, so I'm reopening discussion of the unsolved issue.

ActivityPub:

when the value is the json null type; this means that this field should be removed from the server's representation of the object.

@steve-bate:

The issue is that JSON-LD processing will remove the null-valued property. This make the null-valued property ineffective as a "remove property" instruction.

@evanp:

I'm unsure about how to address this issue. Clearly, at least some JSON-LD tools will elide out null values, so a processor using one of those tools will not receive the "null" versions.

One possible way to thread the needle is to treat the Update object not as content per se, but as a delta on the content, which doesn't necessarily need to match the JSON-LD process, but could be plain old JSON.

I think the next step may be an Erratum, or a note in the Primer about this issue and perhaps others with JSON-LD processing, and perhaps a future change to the specification that may allow other values in the Update object, or even a completely different activity (Patch, maybe?).

@trwnh:

i would say that making c2s and s2s behavior consistent is the best option we have. partial updates always felt like a bit of a hack, as if you miss some partial updates, you will almost certainly end up with an object state that doesn't represent any valid object revision. with full updates, if you miss some updates, you will at least have some valid revision of the object. therefore, i think we should consider an errata and also consider deprecating this functionality. even right now, clients would theoretically not be able to guarantee that a partial update will work as expected, so the primer should probably caution against using this mechanism as well.

---

summary

• Needs Primer: explain the issue with C2S "partial update" and caution against its usage
• Needs Errata: note in the spec that this behavior is incompatible with JSON-LD and AS2
• Next Version: consider deprecating this functionality entirely for above reasons (making c2s and s2s consistent, ensuring that Updates leave the object in a consistent state)

Cross-tagging:

• Semantics of embedded objects of Update activities in collections of activities #408

[trwnh]

additional concern: client-side signing breaks if the server is going to send out a modified activity, for example translating a partial Update (or Patch) into a full Update.

[evanp]

I think we have four next steps.

1. Add an erratum that notes that the use of nulls to delete property values from an object simply doesn't work with JSON-LD processors, and since there's no way to ascertain whether a client or server is parsing with JSON-LD or with plain old JSON, and since the spec says everything is supposed to look like compacted JSON-LD, there's no way to use this feature. The correction of the text would be to remove entirely the sentence 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. We could also note that the original version of the document recommended this, and provide some guidance for servers that receive Update activities with nulls in them.
2. Defining an extension for an extended activity with a new name, like Edit or Patch, that supports partial updates including adding, updating, and deleting properties. Deleting properties in this structure could use one or more different techniques, such as having a special value like rdf:Nil that represents a deleted property. This would give us the full functionality that was originally described in AP, without the null problems.
3. Incorporate that extension into the AS2 context, using the extension policy.
4. Deprecate Update in future versions of AP.

[github-actions]

This issue has been labelled as potentially needing a FEP, and contributors are welcome to submit a FEP on the topic.
Note that issues may be closed without the FEP being created; that does not mean that the FEP is no longer needed.

[nightpool]

deprecating Update entirely feels like throwing the baby out with the bathwater, considering that tons of deployed implementations use S2S updates that do not have this "delete with null" behavior I think adding an erratum deprecating the null behavior specifically is good enough for now.

…

On Fri, Nov 15, 2024, 9:28 AM github-actions[bot] ***@***.***> wrote: This issue has been labelled as potentially needing a FEP, and contributors are welcome to submit a FEP <https://codeberg.org/fediverse/fep/src/branch/main#submitting-a-fep> on the topic. Note that issues may be closed without the FEP being created; that does not mean that the FEP is no longer needed. — Reply to this email directly, view it on GitHub <#477 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZCV7TKFRJ7736W5WRBLD2AYVKPAVCNFSM6AAAAABRB3W2XWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZZGUYTGNZSHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[steve-bate]

The other significant issue with Update for both C2S and S2S is that it conflates the object and target by putting the target URI in the object data. In a Linked Data context that stores activities and has inbox collections (not Mastodon), this means the historical inbox-referenced activities effectively change when updates are processed since the older activity update descriptions reference the modified object's URI. If the URI of the update target were put into the target property, then the inbox history would stay intact and an accurate update history would exist.

(I understand these statements may be confusing if you're not thinking in terms of Linked Data graphs and only considering AP JSON-LD subgraph serializations.)

In a spec revision, I recommend that the target property be used for the update target URI. For backwards-compatibility, Linked Data consumers would need to detect "old style" Updates and move the URI from object to target prior to doing JSON-LD/RDF processing and related graph updates.

Another possibility would be disallow the current style of update. If there were a predicate to indicate replacement (e.g., as:replaces or as:revisionOf), then new versions of objects (with new URIs) would replace previous objects instead of updating them. The entire history could (optionally) be preserved for moderation or other purposes.

[nightpool]

Can you give a more concrete explanation of why object and target would be treated differently here?

[steve-bate]

Can you give a more concrete explanation of why object and target would be treated differently here?

In the C2S partial update case, the object is the partial update description. However, AP C2S partial Updates (typically) use the target URI as the id of the update description, which makes no sense.

Example:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "http://server.example/activity-2",
  "type": "Update",
  "object": {
    "id": "http://server.example/note-1",
    "content": "I like ice cream."
  }
}

Section 6.3 says "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." Again, it doesn't make sense. The object is the update description. Why would that be modified as defined in the update activity?

To be fair, there's no example of a C2S partial update in the spec, so maybe implementors have misinterpreted the requirements. In any case, putting the update target URI in the target property addresses the issue.

Example:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "http://server.example/activity-2",
  "type": "Update",
  "object": {
    "content": "I like ice cream."
  },
  "target": "http://server.example/note-1"
}

[trwnh]

@steve-bate that's an interesting idea and i hadn't considered it. i guess we could say that the Update.object is in JSON Patch form? or alternatively, we introduce an extension property that has @type: @json and leave Update.object alone. something like

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "http://server.example/activity-2",
  "type": "Update",
  "object": "http://server.example/note-1",
  "jsonpatch": [
    {"op": "replace", "path": "/content", "value": "I like ice cream."}
  ]
}

i don't particularly like this because i prefer to think of the actual statements more in terms of rdf, so what i'd really like is an "rdf patch" that can be transformed to/from rdf triples. which is what i think Update is intended to be, or could work as.

maybe even instrument could work here?

Identifies one or more objects used (or to be used) in the completion of an Activity.

so you could say something like

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "http://server.example/activity-2",
  "type": "Update",
  "object": "http://server.example/note-1",
  "instrument": {
    "content": "I like ice cream."
  }
}

in which case, the C2S would need to be reworked to apply instrument as a patch to object. S2S it would "fall back" to

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "http://server.example/activity-2",
  "type": "Update",
  "object": "http://server.example/note-1"
}

for unaware implementations, which would likely just fetch the object from origin again. which also isn't particularly great, since it incurs an extra HTTP request for each recipient. n recipients means n extra requests.

although another caveat: there's also a possible interpretation where a bare id in the Update may be interpreted as removing all properties, since it could be seen as replacing the object with

{
  "id": "http://server.example/note-1"
}

and there is no syntactical difference between this and "object": "http://server.example/note-1".

so i still keep landing on the "cleanest" solution being to switch C2S to using full Update instead of partial Update. yes, this is a normative change; yes, it's backwards-incompatible; but it is functionally the desired behavior.

particularly, there are other considerations for why "c2s full Update" is desirable: parallelism between c2s and s2s. the outbox has "less work to do" because it doesn't need to modify the activity before further delivery. this is especially important in the case where signatures are client-side. a client can sign an Update activity with its client keys, and pass it along to the outbox which handles the side effects opaquely. then, the outbox delivers to the inboxes of the delivery targets, and those recipients can verify that the activity was not tampered with by any intermediate servers. (similar logic is also a pre-requisite condition for e2ee.)

it's frankly not clear what the intended handoff is between the "partial update" and the "full update":

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.

i don't know what "updates from the server to the client" means in this case. it implies that the client is an actor that has its own inbox! how else would the server send an Update to the client?

[steve-bate]

@steve-bate that's an interesting idea and i hadn't considered it. i guess we could say that the Update.object is in JSON Patch form?

It might work with the current definition if there was a special "null" value for deleting properties/triples (like @evanp mentioned). I haven't experimented with it enough to know. From a Linked Data perspective, I wouldn't want an @json-typed property (for the reason you mentioned) and JSON Patch and JSON Merge Patch (RFC 7386) are non-LD JSON (but maybe it's possible to define a JSON-LD context for them?).

Some LD-related references (just food for though):

• Delta: an ontology for the distribution of differences between RDF graphs (W3C, 2001)
• RDF Patch
• Linked Data Patch Format

[nightpool]

In the C2S partial update case, the object is the partial update description. However, AP C2S partial Updates (typically) use the target URI as the id of the update description, which makes no sense.

Okay, I see where you're coming from now, but I think you're substantially misunderstanding how the Update activity is designed and its semantics.

The ActivityPub spec does not (currently, extensions aside), have any concept of an "update description" or "patch object" like you claim. Instead, the idea is that you only serialize the properties that have changed, and this "partial serialization" is used by the backend server to update the object. This isn't saying that the object is a "edit description", but instead just a partial serialization of the full object (just like any JSON-LD document can be a partial serialization of any resource)

The idea was then to use null to represent properties that have been dropped. This is a very effective and simple way to process removed properties. However, this "partial serialization" needs to be handled prior to JSON-LD processing and conflicts with some of the JSON-LD algorithms. I think we can add a special "as:nil" ID to fix this without abandoning the "partial serialization" concept entirely.

[nightpool]

i don't know what "updates from the server to the client" means in this case. it implies that the client is an actor that has its own inbox! how else would the server send an Update to the client?

Presumably it means any Update activities shown in the actor's inbox or otherwise fetched by the client (e.g. by dereferencing the @id property of an Update activity)