Notifying remote servers that they should refetch an object

ActivityPub Server to Server
1

S2S Update:

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.

Presumably sending something like this over S2S would just get the object replaced by an empty copy:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://example.com/activities/1",
  "type": "Update",
  "actor": "https://example.com/actors/1",
  "object": "https://example.com/objects/1"
}

So how would this update/refetch notification be done properly?

2

Going off memory, an IRI is not sufficient for S2S, it must be the inlined updated object value embedded into the Update. C2S too.

Difference is that C2S is a recursive diff and S2S is a complete replacement. This “complete replacement” is ambiguous so go-fed implements it in a specific way.

Your example has an IRI as object so would not be compliant.

3

Yeah, I know it wouldn’t be compliant. But perhaps it could be changed? If not, what other mechanism could be used?

C2S-vs-S2S partial-vs-full is kind of beside the point, as this issue is only relevant to S2S. The desired standardized behavior is “this object has been changed”, as a purely informational thing so that implementations know the rough time of last modification and can do things like refetching or cache expiry.

4

wait, what? why would the example posted not be compliant? The two representations (including an IRI to dereference vs including an embedded object) should be identical on the JSON-LD level.

3 Likes
5

6.3.1, on partial updates:

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.

I interpret “updates … contain the entire new representation of the object” as not being an IRI.

Edit:

Plus the language in 7.3 of the OP talks about the “copy [of the object] supplied in the Update” and “complete replacement of the object”, all of which point at not-IRI but inlined-value expectations.

6

I agree that the spec might expect you to inline the object, but I absolutely disagree that it requires it.

2 Likes
7

I don’t understand. It’s my fault for going so off topic, we should follow up in another thread (Edit: here).

@trwnh, yes! I agree we could make the IRI object value of an update means something like “always means fetch complete replacement” in both S2S and C2S. There’s temporal things to think about too though, since the Update is no longer synchronous with the actual changed object (so multiple cumulative data changes could accidentally be fetched at once). Since the spec is silent on the issue, we would need to get a general consensus on such a convention.

I’m happy to have go-fed support a rule like that, as long as backwards compatibility is supported for the existing rules about inlined values.

Edited multiple times.

8

I agree with nightpool, a bare IRI is completely fine here.

1 Like
9

OK, then. If a bare IRI is fine, then the next question would probably be how this would be handled in existing implementations. If an ActivityPub implementation were to hypothetically use Update in this manner, would it be received and handled properly?