@silverpill @nprofile1q... @nprofile1q... @nprofile1q...
>Usually it's an extra database query. With AcceptFeatureRequest, you can apply side effects right away.

If you are receiving Accept for something, there's probably a check somewhere if the Accepted thing exists to you anyway. Not doing so in the context of this FEP would result in adding a possibly non-existent Object to a Collection. If you store AP Activities/Objects as JSON in your DB the type comes for free with the existence check. If your AP data is more normalized, then yes you would have to join tables using indexes, or possibly re-query the DB to include the type.

Reject might need the same checking as Accept or might not depending on the target.

@silverpill @nprofile1q... 2

@silverpill
>It is not the same thing because you skip one expensive operation: determining the subtype of activity.

This is an expensive operation, but in a different way. Determining the subtype isn't expensive computationally, it's expensive on storage, since you now need an Object type index in the database. The Activity subtype is the same as Object type that you fetch from the DB first.

>Is that a problem? I already have different parsers and different builders for different activities.

Depends, it's increased code complexity that previously didn't need to exist. Keeping the same Activity type results in more code for every new subtype, but a completely new Accept* type probably results in even more code depending on codebase.

@Listens to Baroque while coding murder.exe :newt: @Vinnewed Goblin Apple finally released the airpods subwoofer?

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

@Snacks @Listens to Baroque while coding murder.exe :newt: My guess is that you must not use headphones.

@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

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

@meso @Lehmä :heart_pride: Poníčková, kombajnérka žalu
czech-republic-mentioned.png

@just cell
cybersecurity-cat-girl.png