Why did #ActivityPub create special behaviors such as Like, Announce and Block (and the Undo variants) instead of using Add to or Remove from the associated Collection objects?
-
@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 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?
-
@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
-
@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?
-
@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?
@eyeinthesky @smallcircles you could, but you don't necessarily have to. Depends if adding to that collection has a social action besides the add I think.
Say I have a boops collection which contains actors I've booped. I could have a Boop activity with a side effect (because I want them to know I've booped them), or I could not, and just notify them that I added their Actor to this Collection.
-
@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.
-
@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 @smallcircles that's the thing though! The likes collection doesn't contain activities, it contains objects.
-
@eyeinthesky @smallcircles that's the thing though! The likes collection doesn't contain activities, it contains objects.
@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
-
@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
@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)
-
@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’m not sure how you define “social meaning”, but if you Add a Boop to my boops collection you socially booped me. I suppose a Boop activity is needed either way, but overloading the meaning to include implicit collection management seems dubious to me.
-
@eyeinthesky @smallcircles that's the thing though! The likes collection doesn't contain activities, it contains objects.
@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 (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)
I just responded in the other thread about #ForgeFed way of dealing with Issues and PR's, emphasizing the actor model in the #ActivityPub specs.
Guess it depends on the nature of your extension and its desired functionality how you model things, but ForgeFed chose to have a dedicated actor, a TicketTracker, to manage the collection. Big advantage is that it become a truly encapsulated service with its own business logic, fronted by an AP actor for interoperable network communication.
🫧 socialcoding.. (@smallcircles@social.coop)
@thisismissem@hachyderm.io @deadsuperhero@social.wedistribute.org I was looking at #ForgeFed which is a very sizable #ActivityPub extension (constituting the "Code forge" app domain in app-centric view, but arguably "Software development" top-level business domain in a service-oriented fedi). The way that things are modeled here adheres more to the actor model where there's a Factory actor, which in turn creates resource actors that expose various sub-domains. For instance for the management of Issues and PR's there's a TicketTracker actor to obtain via a Factory actor on a forge instance. Though I'm not sure whether I'd modeled that in similar fashion, it is a fascinating direction where we focus much more on good protocol extension design. All in all AS/AP offers a very granular foundation that allows for very interesting architectures, if only we dare explore them and do not dogmatically stick to some engrained notion how "social media" ought to be. I see #SocialMedia as but a small subset of #SocialNetworking.
social.coop (social.coop)
-
@thisismissem @smallcircles I’m not sure how you define “social meaning”, but if you Add a Boop to my boops collection you socially booped me. I suppose a Boop activity is needed either way, but overloading the meaning to include implicit collection management seems dubious to me.
@eyeinthesky @smallcircles yeah, and this is a side effect of the activity (e.g., Like) adding to both my likes collection and the likes collection on your post.
So would my add be targeting two collections with an Activity?
What about Announce? That's add to my outbox, add to my boosts collection, and add to your post's boost collection.
-
@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 I suspect this is incorrect. I am pretty sure the likes collection contains only objects, not the activities.
@evan was there an erratum for this? I feel like there was?
-
I just responded in the other thread about #ForgeFed way of dealing with Issues and PR's, emphasizing the actor model in the #ActivityPub specs.
Guess it depends on the nature of your extension and its desired functionality how you model things, but ForgeFed chose to have a dedicated actor, a TicketTracker, to manage the collection. Big advantage is that it become a truly encapsulated service with its own business logic, fronted by an AP actor for interoperable network communication.
🫧 socialcoding.. (@smallcircles@social.coop)
@thisismissem@hachyderm.io @deadsuperhero@social.wedistribute.org I was looking at #ForgeFed which is a very sizable #ActivityPub extension (constituting the "Code forge" app domain in app-centric view, but arguably "Software development" top-level business domain in a service-oriented fedi). The way that things are modeled here adheres more to the actor model where there's a Factory actor, which in turn creates resource actors that expose various sub-domains. For instance for the management of Issues and PR's there's a TicketTracker actor to obtain via a Factory actor on a forge instance. Though I'm not sure whether I'd modeled that in similar fashion, it is a fascinating direction where we focus much more on good protocol extension design. All in all AS/AP offers a very granular foundation that allows for very interesting architectures, if only we dare explore them and do not dogmatically stick to some engrained notion how "social media" ought to be. I see #SocialMedia as but a small subset of #SocialNetworking.
social.coop (social.coop)
@smallcircles @eyeinthesky yeah, making everything an Actor is certainly a choice, and you could do that
-
@eyeinthesky @smallcircles I suspect this is incorrect. I am pretty sure the likes collection contains only objects, not the activities.
@evan was there an erratum for this? I feel like there was?
@thisismissem @smallcircles @evan It makes sense to me. Someone liked a local object. We wouldn’t add the liked object to the liked object “likes” collection (it would be the same object). It seems that only the activity (and collection count) is interesting. Maybe you are thinking about the “liked” collection? (Different topic, but it seems that this *should* be a collection of activities too. Dropping the activity loses info such as the Like timestamp.)
-
@smallcircles @eyeinthesky yeah, making everything an Actor is certainly a choice, and you could do that
I think we underrated the power of the actor model and the extent we can incorporate it on the #ActivityPub fediverse. Somehow we got eternally stuck in talking about HTTP plumbing and core protocol capabilities that we never fleshed out thoroughly in order to be able to just focus on the higher-level concerns of app and service modeling.
Actor systems based on loosely-coupled event-driven architecture, delegation, supervision, supervision strategies, inbox strategies, let-it-fail, actors fronting domain aggregates, service-orientation, etc.
-
I think we underrated the power of the actor model and the extent we can incorporate it on the #ActivityPub fediverse. Somehow we got eternally stuck in talking about HTTP plumbing and core protocol capabilities that we never fleshed out thoroughly in order to be able to just focus on the higher-level concerns of app and service modeling.
Actor systems based on loosely-coupled event-driven architecture, delegation, supervision, supervision strategies, inbox strategies, let-it-fail, actors fronting domain aggregates, service-orientation, etc.
The biggest folly imho is this idea of "let's cram every domain into #ActivityStreams somehow". Flatten everything and project it onto this small set of social primitives that AS defines.
It is once more a choice of pragmatism: "Hey, I've seen it working with Mastodon, so I copied that. And #LinkedData extension mechanism is a handwaved horror show".
So understandable perhaps that we did it. But now we must overcome this trend which has taken stubborn root and drags the ecosystem down.
-
Why did #ActivityPub create special behaviors such as Like, Announce and Block (and the Undo variants) instead of using Add to or Remove from the associated Collection objects? I have a similar question for outbox and inbox POST, which is an implicit Add to those collections.
When adding support for extended collections, is an new collection-specific Activity preferred over Add/Remove? FWIW, I see Mastodon uses Add/Remove for pinned and featured posts.@eyeinthesky I think
Add/Removeshould be used for extended collections.Like,Announceetc look like legacy / tech debt to me. -
@eyeinthesky I think
Add/Removeshould be used for extended collections.Like,Announceetc 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.
-
@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,UpdateandDelete. Everything else can be constructed from them.
