You have a right to cache the payload, unmodified. So you’re correct,
server_b will locally store federated payloads from
server_a, meaning it is up to your specific application whether you want your app’s logic to:
- Store everything ever sent to you and rely heavily on your cache; or
- Just store the IRIs and then re-fetch from a peer server whenever you need the body of the object (no caching); or
- something in between
That is application-specific. In today’s software, typically only the original actor sends an
Update Activity – if the software even allows Updates at all.
The question of “who can do what” is again, unfortunately, application specific. The
Delete Activities are sent out to allow coordinated “cache control” of these copies living in other federated peers. Some applications skip the
Update logic and only federate
I think a key point of confusion may be: In your example, you have a cross-instance federated
Update. That is,
https://anotherone.net/thomas is attempting to
Update something originating from
https://example.com/. This is not the simple case, but a very gnarly case due to how IRIs today are coupled with their originating server. I think there are discussions on this SocialHub going into great debate trying to solve this kind of general problem (“sending an activity about data living on another instance”) but I’d propose excluding it for now, and revisiting it later.
With that in mind, that means an app’s primary focus is going to figure out if it should let only the original actor also send an
Update about the data it “owns” – letting only
https://example.com/max send an
https://example.com/max/task_72 – or allow anyone on
https://example.com send that
Update. I can’t remember off the top of my head if some peer software already bakes that assumption into their processing of incoming federated activities, in which case it is also a compatibility problem now.
One point of detail: the
Activity may have the actual data you’re interested in (
Task, in this case) embedded in its body. I think most implementations rely on IRI indirection here. For example, a complete discovery round of fetching could look like this:
https://example.com/max/outbox may yield:
2a) You then iterate – I’ll just go through one iteration here – and fetch the first
2b) You then fetch
https://example.com/max/task_72 and obtain the latest version of it (note: this will also be the same payload when fetching the
Create.object for this task):
- If still iterating, go to 2a.
Ignoring the cross-federated update, the simple path is: each instance of federated software is able to “own” and operate on (update and delete) their own data, but share it. Peers receiving that data can then generally generate new data in response to such data, and also share it. They can also locally delete it (ex: moderation) but it does not result in mass censorship for other federated software instances.
I’m not sure what interactions you’re interested in, but if that previous paragraph is insufficient for your use-cases, you’re not alone. Great questions!