@eyeinthesky @smallcircles (funnily enough, in AT Protocol, we only have collections we add records to, all the social layer is defined by applications above, which receive all the changes to records and infer meaning from that)
Post
Replies:
15
@eyeinthesky I think Add / Remove should be used for extended collections. Like, Announce etc look like legacy / tech debt to me.
@silverpill@mitra.social add and remove feel more like building blocks than actual activities.
It would never capture the nuance of many of the activities that it would purportedly represent.
@julian @thisismissem @eyeinthesky @mariusor @smallcircles
Yes, they are building blocks, together with Create, Update and Delete. Everything else can be constructed from them.
@julian @thisismissem @eyeinthesky @mariusor @smallcircles Maybe Offer, Accept and Reject are needed too. Follow can be replaced with Offer(Relationship), I am not sure if there's a way to do it with Add / Remove alone.
@eyeinthesky @smallcircles because the activity isn't just about the change of the collection, but also notifying the other party our social intention. It could have required Like + Add, but that feels cumbersome and developers love side-effects.
@thisismissem @smallcircles The weird thing about Like+side_effects vs Add(Like activity to “likes collections”) is that the side effect is Add Like to “likes collection”. lol They are both one inbox activity.
@eyeinthesky @thisismissem @smallcircles i would use as:result for this -- the *result* when you Accept the Like activity is to Add it to the likes collection... if you care about that level of detail. most people only care about the Like. maybe even less than that! (synthesizing a statement such as :bob :likes :this.)
@trwnh That's a neat idea. Looks like we can get rid of side effects completely by making result a special property.
@eyeinthesky @smallcircles that's the thing though! The likes collection doesn't contain activities, it contains objects.
@thisismissem @eyeinthesky @smallcircles likes contains Like activities; shares contains Announce activities; the exception is followers not containing the Follow activity (or not having a follows collection) (or not doing the better thing which is subscription management)
@thisismissem @smallcircles Per the AP spec… “The side effect of receiving this in an inbox is that the server SHOULD increment the object's count of likes by adding the received **activity** to the likes collection if this collection is present.” (emphasis mine)
@eyeinthesky @smallcircles and how do I infer social meaning from you adding an object to a collection? I could only do that if I was adding an activity to a collection
@thisismissem @smallcircles I know feelings will vary, but it doesn’t feel cumbersome to me. It seems more logically consistent and less functionally redundant. Side-effects can still be defined for specific target collections. What do you recommend for extension collection management?
@eyeinthesky @smallcircles yeah, there's those that like side-effects and those that dislike side-effects. Both are valid, AP just chose side effects.
I'm not sure I understand your question
@thisismissem @smallcircles If I define an extension that uses a collection, should I define a special activity for managing the collection instead of using Add/Remove?
