Conversation

Notices

1. Embed this notice
   silverpill (silverpill@mitra.social)'s status on Sunday, 14-Jun-2026 20:52:48 JST silverpill

   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. Another day, someone proposed to use Follow activity for "watching a thread".

   So now, when you receive a standard activity, you need to use increasingly complicated heuristics to figure out what the activity does, because it is not possible to infer that from its type anymore.

   This has to stop. I think we need to start giving our activities better names.

   #ActivityPub

   • Blurry Moon and pistolero like this.
   • pistolero repeated this.
   • Embed this notice
     lainy (lain@lain.com)'s status on Sunday, 14-Jun-2026 21:07:34 JST lainy

     in reply to

     • Phantasm
     @phnt @silverpill looking forward to the first activity with an array of types targeting an object with an array of types
     Blurry Moon and pistolero like this.
   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Sunday, 14-Jun-2026 21:07:35 JST Phantasm

     in reply to
     @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.
     pistolero likes this.
     Blurry Moon repeated this.
   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Sunday, 14-Jun-2026 21:30:29 JST Phantasm

     in reply to

     • lainy
     @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
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 14-Jun-2026 21:30:29 JST silverpill

     in reply to

     • lainy
     • Phantasm

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

     pistolero likes this.
   • Embed this notice
     lainy (lain@lain.com)'s status on Sunday, 14-Jun-2026 21:31:49 JST lainy

     in reply to

     • Phantasm
     @silverpill @phnt amazing
     pistolero likes this.
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 14-Jun-2026 21:37:51 JST silverpill

     in reply to

     • Phantasm

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

   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Sunday, 14-Jun-2026 21:40:26 JST Phantasm

     in reply to

     • lainy
     @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.
     lainy, Blurry Moon and pistolero like this.
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 14-Jun-2026 22:07:52 JST silverpill

     in reply to

     • marius

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

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Sunday, 14-Jun-2026 22:07:54 JST marius

     in reply to

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

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 14-Jun-2026 22:22:48 JST silverpill

     in reply to

     • Raphael Lullis
     • Phantasm

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

   • Embed this notice
     Raphael Lullis (raphael@mastodon.communick.com)'s status on Sunday, 14-Jun-2026 22:22:49 JST Raphael Lullis

     in reply to

     • Phantasm

     @silverpill @phnt

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

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 14-Jun-2026 22:30:32 JST silverpill

     in reply to

     • marius

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

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Sunday, 14-Jun-2026 22:30:34 JST marius

     in reply to

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

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 14-Jun-2026 22:36:59 JST silverpill

     in reply to

     • Raphael Lullis
     • Phantasm

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

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

   • Embed this notice
     Raphael Lullis (raphael@mastodon.communick.com)'s status on Sunday, 14-Jun-2026 22:37:00 JST Raphael Lullis

     in reply to

     • Phantasm

     @silverpill @phnt

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

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 14-Jun-2026 22:48:36 JST silverpill

     in reply to

     • marius

     @mariusor What kind of side-effect hint would you prefer?

     1. Specialized activity name

     { "type": "AcceptFeatureRequest" "object": "https://social.example/request" }

     2. Additional property

     { "type": "Accept", "object": "https://social.example/request", "objectType": "FeatureRequest" }

     3. Embedded object (possibly partial):

     { "type": "Accept", "object": { "id": "https://social.example/request", "type": "FeatureRequest" } }
   • Embed this notice
     Blurry Moon (sun@shitposter.world)'s status on Sunday, 14-Jun-2026 22:59:18 JST Blurry Moon

     in reply to

     • Phantasm
     @phnt @silverpill I am using accept for verifiable credential acceptance in Egregoros and yes it is obvious it will get out of control
   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Sunday, 14-Jun-2026 22:59:19 JST Phantasm

     in reply to
     @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.
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 14-Jun-2026 22:59:22 JST silverpill

     in reply to

     • Phantasm

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

   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Sunday, 14-Jun-2026 22:59:23 JST Phantasm

     in reply to
     @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.
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 14-Jun-2026 23:10:23 JST silverpill

     in reply to

     • marius
     • Phantasm

     @phnt @mariusor I am okay with this option https://socialhub.activitypub.rocks/t/fep-5624-per-object-reply-control-policies/2723/65

     But the subtype is not always determined by object. Sometimes it's target or another property. Nowadays my preference is 1.

   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Sunday, 14-Jun-2026 23:10:24 JST Phantasm

     in reply to

     • marius
     @silverpill @mariusor 2
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 14-Jun-2026 23:33:44 JST silverpill

     in reply to

     • marius

     @mariusor (3) carries the risk of cache poisoning because the recipient can't tell whether the embedded object is full or partial.

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Sunday, 14-Jun-2026 23:33:46 JST marius

     in reply to

     @silverpill hypothetically the last one is the one I find the most consistent with the way I interpreted the Activity vocabulary spec, and the way I implemented the ActivityPub processing state machine.

   • Embed this notice
     Steve Bate (steve@social.technoetic.com)'s status on Wednesday, 17-Jun-2026 03:56:44 JST Steve Bate

     in reply to

     @mariusor @silverpill Object type-specific Accept activity types 👎 It appears to me that some of these concerns are implementation-specific (activity processing and caching techniques) and some are related to not understanding the spec (wrt partial objects).

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Wednesday, 17-Jun-2026 03:56:45 JST marius

     in reply to

     @silverpill in the context of Mastodon's FEP, perhaps cache poisoning could be a problem, but from the context of ActivityPub, there's no "cache poisoning" because the canonical version of an object is the one the server retrieves explicitly based on its ID, anything else is hearsay and should not be trusted by default.

     Also I find very hard to reason about what you call "cache poisoning" when the entity that serves the object is the same with the one that sends the activity.