Brittle guidance regarding idempotent activities

[Tamschi]

This is regarding

• https://www.w3.org/wiki/index.php?title=ActivityPub/Primer/Follow_activity&oldid=116221#Multiple_Follow_activities
• https://www.w3.org/wiki/index.php?title=ActivityPub/Primer/Like_activity&oldid=116220#Multiple_Like_activities

(current versions as of writing).

If only the oldest activity of an idempotent kind is stored, it's relatively easy to (due to very unreliable network conditions or other bugs) arrive at a state where the sender is permanently unable to directly remove such a relation because their instance doesn't allow them to re-send an Undo-activity correctly targeting the activity that originally established the relation.

To mitigate this,

1. the receiving server of subjectively superfluous Follow or Like activities should¹ replace the activity @id they have on file for the existing relation with the latest one that would have created it while still cancelling any other side-effects of the latter.
2. If a stored Undo targeting this new Follow or Like has already been received and buffered, its effects should be applied (as if) after updating the stored @id.

Footnotes

1. arguably "SHOULD", but I'm not sure if those keywords are considered appropriate for use in the Primer ↩

[Tamschi]

This was originally discussed in #381.

(Thanks @snarfed for pointing this out! I tried searching for it but must have just barely missed the keywords.)

[evanp]

I agree that it probably makes sense for maximum interoperability for the receiving server to store not only the first Follow or Like activity, but to store additional Follow or Like activities, primarily for Undo. It is possible to ignore the id of an activity being undone, and just execute based on shape, but there are probably some security issues there. I'm going to mark this ticket as requiring an update to the primer, in order to suggest maximizing Undo functionality.

[nightpool]

what security issues?

…

On Fri, Dec 27, 2024, 11:22 AM Evan Prodromou ***@***.***> wrote: I agree that it probably makes sense for maximum interoperability for the receiving server to store not only the first Follow or Like activity, but to store additional Follow or Like activities, primarily for Undo. It is possible to ignore the id of an activity being undone, and just execute based on shape, but there are probably some security issues there. I'm going to mark this ticket as requiring an update to the primer, in order to suggest maximizing Undo functionality. — Reply to this email directly, view it on GitHub <#485 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZCV7ATBSLWW37MLCMG632HWEFBAVCNFSM6AAAAABUD4Z53GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRTHA4TANBXGY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>