The Update Activity: More Than Caching

[cjs]

What part of the spec mentions this? I mean, I think it’s probably good practice to make your Updates quickly and meaningfully, but I would not , for example, suggest that a server break up one logical change that touches many properties into a series of many Update messages—that just sounds like a huge out-of-order/synchronization problem waiting to happen.

Nothing, it’s a property of the guidance.

I agree with your suggestion, I’m not suggesting it either. Nowhere am I suggesting “breaking things down”

The implication throughout the guidance and the way C2S and S2S seem to interoperate is:

• 1 user edit generates 1 C2S Update
• That C2S Update is sent to the Server, which generates 1 S2S Update with v2 of object
• Server federates that 1 S2S Update with the v2 of object (which represents 1 logical user edit)

That allows the originating Server and federating servers, when displaying their UI, to collapse “meaningless” edit histories (however each of them defines that, doesn’t matter that they disagree), and show “meaningful” ones.

What I am saying instead, is to not bundle up edits together C2S:

• 1 user edit generates 1 C2S Update
• That C2S Update is sent to the Server, which sticks it in a processing queue
• 1 user edit generates another C2S Update
• That C2S Update is sent to the Server, which sticks it in a processing queue
• Server processes its queue in batch, generating v2 of object with both edits
• Server federates that 1 S2S Update with the v2 of object (which represents 2 logical user edits)

I don’t see how maintaining object versioning would require an inlined object.

If you fetch an IRI after an Update, another second/third/… Update may have already been issued by the user, so a federating peer has no guarantee they’re obtaining a whole edit history.

• 1 user edit generates 1 C2S Update A
• C2S Update A is sent to the Server, which updates object to v2, and generates 1 S2S Update A with IRI
• Server federates that 1 S2S Update A with IRI
• Peer received S2S Update A, decides to fetch a bit later
• 1 user edit generates 1 C2S Update B
• C2S Update B is sent to the Server, which updates object to v3
• Peer fetches the object due to S2S Update A, but obtains v3 with no way to know whether its the accumulation of >1 user edits.

If Peer and originating Server then try to show the edit history, they’ll not be sync’d.

I don’t want to support “object versioning” natively in ActivityPub, as it opens all sorts of cans of worms for edits that later restrict intended visibility of an object. But in the meantime, following the spec’s guidance does have this property of guaranteed sharing of the complete edit history.

Is it worth preserving? For an application I’ve had in mind (and may soon have the paperwork to actually begin implementing), it’s a property I’d like to have (peers and originating servers able to display the same versioned history). But I’m open to the idea that versioning history may just be a separate problem.