I've been reviewing the new FEP from the Mastodon team today, and one thing that caught my attention is the use of Accept and Reject activities for managing approvals.
-
@silverpill @lain Use case for type=recipe not found.
>Cookifed is a free and federated recipes management app and cooking social network. Using ActivityPub, users can share their recipes publicly or just with friends across multiple instances.
Actually not a bad idea considering the current state of recipe sites. -
@phnt With
AcceptFeaturedyou don't need to determine anything. Because the object type is right here in the activity nameWhat is the practical difference between having to agree on the meaning of "Type + verb" vs "VerbType"?
-
@silverpill I think you're wrong. It feels perfectly natural that the same activity can be used with different objects. That's the whole purpose of the Activity vocabulary itself being split between activities and objects, isn't it?
And yes, that sometimes means that different side-effects need to be implemented for processing the same type of activity.
@mariusor Wrong about what, using different names for different things?
Only a few activities from Activity vocabulary work well with any type of object. For example
CreateandUpdate. -
@silverpill You ideally should verify that AcceptFeatured refers to the type of the Object as expected, effectively doing the same thing anyway. You also need to add that as a supported type to your Acccept/Reject validator since they are basically the same, you have to modify your activity builder, if you have one, to create these new types if you wish to support creation and not just ingestion.
So instead of some long switch/case statement on an Object type, you now have a long list of Accept*/Reject* types that all have the same semantics just operating on different types. And more handling in your validators/builders.
The same argument can be made about Create/Update Activities which operate on a bunch of Object types. CreateNote/UpdateNote/UpdateActor/... doesn't make sense in my head as well.You ideally should verify that AcceptFeatured refers to the type of the Object as expected, effectively doing the same thing anyway.
It is not the same thing because you skip one expensive operation: determining the subtype of activity.
You also need to add that as a supported type to your Acccept/Reject validator since they are basically the same, you have to modify your activity builder, if you have one, to create these new types if you wish to support creation and not just ingestion.
Is that a problem? I already have different parsers and different builders for different activities.
The same argument can be made about Create/Update Activities which operate on a bunch of Object types. CreateNote/UpdateNote/UpdateActor/... doesn't make sense in my head as well.
CreateandUpdatehave an embedded object, so they do not require specialized names. -
@mariusor Wrong about what, using different names for different things?
Only a few activities from Activity vocabulary work well with any type of object. For example
CreateandUpdate.@silverpill wrong about thinking that the activity type is the only meaningful information about the side-effect of its reception.
The official specification already has a case where Create/Delete have slightly different logic based on their objects:
https://www.w3.org/TR/activitystreams-vocabulary/#h-motivations-crud
vs.
https://www.w3.org/TR/activitystreams-vocabulary/#h-motivations-relationships
PS. I'm not defending the Mastodon FEP, but clarifying that the underlying assumption of using existing vocabulary for what is basically the same operation, be it on different object types, makes sense.
-
What is the practical difference between having to agree on the meaning of "Type + verb" vs "VerbType"?
-
So doesn't it mean that, in practice, your objection to the FEP is purely about your personal preference?
-
@silverpill wrong about thinking that the activity type is the only meaningful information about the side-effect of its reception.
The official specification already has a case where Create/Delete have slightly different logic based on their objects:
https://www.w3.org/TR/activitystreams-vocabulary/#h-motivations-crud
vs.
https://www.w3.org/TR/activitystreams-vocabulary/#h-motivations-relationships
PS. I'm not defending the Mastodon FEP, but clarifying that the underlying assumption of using existing vocabulary for what is basically the same operation, be it on different object types, makes sense.
@mariusor Activity type is not the only meaningful information about the side-effect, but in many cases a custom type could help with the identification.
-
So doesn't it mean that, in practice, your objection to the FEP is purely about your personal preference?
-
I'd argue that #2 (more efficient processing) is not the case, and is highly dependent on implementation.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login