#social 2020-09-07
2020-09-07 UTC
sl007 and mib_nnemgv joined the channel
# 
mib_nnemgv in activitypub, when multiple actors what to update the same object, which way would you recomment to deal with collisions? As far as I know the activitypub specification doesn't say anything about this, it only says "the object should be updated if the [remote] actor has permission", but I don't see any mention of conflict resolution.
sl007 joined the channel
# nightpool[m] mib_nnemgv: do you mean in the c2s case or the s2s case? in the s2s case whenever you get an Update activity I think it's prudent to refetch the object from the origin without regard for the properties contained in the serialized payload
# nightpool[m] if the activity contains an `updated` property you could also use that to determine which was more recent
# mib_nnemgv nightpool[m]: I wasn't thinking of either c2s/s2s, but just in general. I mean... the way AP is described and also the way "social" apps implement it, everything happens locally and the activities are basically just a notification. For example I create a Note and notify my followers. But I don't see any implementation where multiple users are allowed to
# mib_nnemgv update an existing object. For example multiple users editing the same Note object. How would you recomment to handle this concurrency?
# BradKoehn[m] The spec doesn't handle this case at all, from what I can tell. One way to handle it would be to include a link to the Create/Update activity you based your update upon. At least then servers could know if a collision has occurred.
# mib_nnemgv BradKoehn[m]: that's pretty much the same of using an "updated" property like it was suggested by nightpool, right? Or any random string would do, probably
# nightpool[m] mib_nnemgv: I'm not sure I understand what you mean by "generally". AP is two specific protocols, the c2s and the s2s protocol. neither include specific considerations for Update collisions but there are common sense strategies for handling them with both
# BradKoehn[m] > <@irc_mib_nnemgv:cybre.space> BradKoehn[m]: that's pretty much the same of using an "updated" property like it was suggested by nightpool, right? Or any random string would do, probably
# BradKoehn[m] The benefit of using the ID of the activity upon which you're basing your update is that the receiving server can fetch the object and discover what you changed.
# mib_nnemgv BradKoehn[m]: only the last change though, unless it keeps a collection of links
# BradKoehn[m] The last change links to the previous one, and if your server works like mine does, all of the messages (and thus changes) are preserved.
sl007 joined the channel