Tracking Issue: Should idempotency (or not) of certain activities be explicit?

[bumblefudge]

Great point here in a thread about something tangential. Want to make sure this is picked up later if a new major version of the spec is ever undertaken.

In case the above link breaks between now and then, the relevant quote from @trwnh is:

is there any idempotency in processing activities, either from a C2S or S2S perspective? I have seen it proposed (albeit semi-unseriously) that you could send multiple Follow or Like activities in order to represent a “super follow” or a “super like”. The only explicitly idempotent bit is the side effect of adding the object to an unordered Collection, which is technically a set and therefore theoretically can’t contain duplicates. A more “common usage” interpretation would hold that follows and likes should be idempotent, but there’s nothing actually establishing this one way or the other. The most naive implementation of, say, C2S or S2S Like, is to handle each Like separately if each activity uses a different id. It then follows that you could post 10 likes of the same object and subsequently undo 3 of those specific activities. And for what it’s worth, adding each activity to either a Collection or an OrderedCollection will not be deduplicated, because each of those activities has a different id. You’ll effectively need to add an implementation quirk that tries to dedupe activities by their shape rather than by their id, in which case… of what purpose is the id? Why bother looking up the original id at all?

[snarfed]

Really great thought experiment! There's clearly a gap between AP's technical activity processing and the user-visible semantics. If you send two Likes of a given object, with two different ids, and then Undo one of them, AP may specify that the other one remains in the likes/liked collections. OK. But that may not match user expectations, ie if a user currently likes a post, and then they unlike it, they then no longer (visibly) like it.

For "stateful" toggle activities like these - likes, follows, etc - do we implicitly expect server implementations to first look up whether the toggle is "on" for a given user, ie whether they have an "outstanding" Like activity, and reuse that id instead of generating a new Like? If so, is it eventually worth standardizing or at least documenting these different activity types/shapes and their expectations?

[trwnh]

I bring the previous paragraph/point as an example because I assume blocks are idempotent in “common usage”. If this is indeed the case, then perhaps this should be stated as explicit guidance, and all such “idempotent activities” should be identified clearly. But I can also foresee challenges in trying to establish a conclusive judgement on this. Look no further than Announce – on Twitter and Twitter-like systems, the “retweet” can only be performed once, but on Tumblr and Tumblr-like systems, the “reblog” can be performed any number of times, including in direct succession. Similar reasoning can be extended to pretty much any other activity type. In fact, if you treat all activities as generic posts or items in the “activity stream”, you might not care if someone does a Follow of the same person multiple times in a row. There is a disconnect between each activity as a resource and each activity as a procedure call. I’m not entirely sure that this disconnect can be fully reconciled.

[trwnh]

@snarfed I think "stateful" is a really dangerous thing to start building around. If you start explicitly assuming there is a state, then you will eventually consider whether it is necessary to synchronize that state... and that's not always the same as synchronizing the resources themselves. You have to keep track of whether an activity was processed or not, which possibly means retrying delivery if you don't get an explicit signal telling you the activity was successfully or unsuccessfully processed.

I'd rather keep it as an implementation detail or decision as to whether certain activities should be idempotent, but I recognize that this can lead to UX fractures between systems that assume one way vs systems that assume the other way. For my part, I'd recommend trying to separate the side-effects from the resources. Architect the system such that you only ever care about which objects are in which collections, and "state synchronization" is as easy as fetching the latest collection. Of course this requires objects to explicitly be in collections, rather than only implicitly grouped together by assumption. For example: explicitly maintaining a profile rather than just assuming that all Create/Announce/etc represent posts on the same profile.

For what it's worth, the answer to your Like example is that you would end up with the object no longer in liked, but one of the two Like activities would remain in likes on the object.

[snarfed]

Absolutely right, hence "gap between AP's technical activity processing and the user-visible semantics."

One option would be to punt on this in AP and say that product behavior and user-visible semantics are out of scope. I'm not sure about that, since AS2 vocab seems to bring them pretty squarely into scope, but 🤷‍♂️.

Another option would be to define a very basic first level of semantics. For example, in this case, which activities should be stateful (idempotent) vs stateless. For example, reposts could be stateless, ie you could repost the same post multiple times, like Tumblr, but likes and followers could be stateful, ie a first like would toggle that state on for a given object, successive likes would do nothing, and an undo of any like would toggle it back off.

(I expect any semantics like those would be SHOULD, not MUST.)

I don't actually know which of those options AP should do, if either, and if we did semantics, I'm sure there would be lots of debate over which to use. Interesting to think all this through though.

[bumblefudge]

In the case that:

• AP2 spec takes no opinion,
• AP2 spec doesn't start for 2 years,
• and/or AP2 spec makes it a SHOULD not a MUST,

Might it help to have a FEP or two defining how an implementation handles this? That way, at least the "assumptions about which path another instance/codebase took on this issue" could be derisked by reference to FEP implementation conformance (however that's signaled)...

[trwnh]

reposts could be stateless, ie you could repost the same post multiple times

The hard part is that all activities can be considered a "post" -- there is no real concept of a "post" in the social media sense. A Like activity can be directly translated into a "John liked this" type of post, as seen on Facebook. You could even treat a Follow like this, albeit you can't actually verify that it was accepted. "John followed Sally" would more accurately be expressed to external audiences as "John requested to follow Sally".

[evanp]

We already have guidance on using the Follow activity, noting that the membership in followers and followed should be unique.

In issue triage, I added the Like activity processing, and noted that membership in the likes collection should be unique by actor.

[evanp]

For both of the above pages, I gave some Postel guidance on what to do with multiple Like or Follow activities, which have unspecified behaviour: originators should not send them (unspecified behaviour), and recipients should quietly ignore them (again, unspecified behaviour).