I see this from the other direction — I think it's great that we have a unified vocabulary for approvals and rejections. Why would we need a separate FeaturedItemAccept when Accept will do nicely?

From a code organization perspective it's as complicated as you make it. For the more overloaded activities, a switch..case separates out discrete logic into physically different blocks. You could break that out to separate functions for organization.

Once an activity handles more than one or two variants you begin to learn to make fewer assumptions based on type <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f60f.png?v=8aecdd5494b" title="" />

@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.

@silverpill
>And one thing that caught my attention is the use of Accept and Reject activities for managing approvals.

This is an ActivityPub issue more than anything else. The "spec" is clear that the side-effects are to be determined by the type of the Object. There is no other indication, you effectively must check the type of the Object referenced. And I think that is correct, the same way Mastodon is correct in its usage of these two Activity types.

If you split the type for other Accept/Reject Activities, like AcceptFeatured or whatever, you are still left with more type determining logic anyway [at least in function non-pattern matching languages :)]. You just moved it somewhere else instead.

@phnt @silverpill looking forward to the first activity with an array of types targeting an object with an array of types

Do you also use the same 10 names for all variables in your code?

@lain @silverpill Somebody probably made that already. Objects with type arrays have been talked about recently-ish I think. Those are even more insane and should be made into a specific type instead.

https://codeberg.org/fediverse/fep/src/branch/main/fep/2277/fep-2277.md#multi-typing

@phnt With AcceptFeatured you don't need to determine anything. Because the object type is right here in the activity name

@phnt @lain Not long ago I saw a Create activity from Cookifed and the object type was ["Note", "Baking"].

@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.

@silverpill @phnt amazing

@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.

@silverpill @phnt

What is the practical difference between having to agree on the meaning of "Type + verb" vs "VerbType"?

@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 Create and Update.

@phnt

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.

Create and Update have an embedded object, so they do not require specialized names.

@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.

@raphael @phnt I don't think there is a difference.

@silverpill @phnt

So doesn't it mean that, in practice, your objection to the FEP is purely about your personal preference?

@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.

@raphael @phnt In a way, yes. My personal preferences:

1) self-describing objects (better DX)
2) more efficient processing