1·
3 months ago@[email protected] @[email protected] @[email protected] The point @[email protected] is trying to make is that side-effects differ based on the Object an Activity points to. So if you are ingesting an Activity of type Accept, you have to dereference the Object, fetch it or look it up in the DB, check the type of the Object and then decide what to do.
With pseudo-namespaces, you see an Activity type that is unique to an Object type. There is no special handling for each type as it doesn’t matter. Depending on how painful implementing new AP types is in your software, using namespaces is cleaner and more obvious. If it’s a pain to implement new types in your software,…
@benpate @technical-discussion
>Given all of the different kinds of activities we have to accept, it seems like this would already be a requirement for any ActivityPub server, yes?
More or less yes, but that doesn’t mean it must be that way forever. Currently Accept/Reject is mostly only for follows for example. Now if I add something like group chat Invites, the two would have completely different side-effects.
I don’t really have a preference for one over the other, as the language I would use solves the type check for me via pattern matching. But if it wouldn’t, the result would probably include a giant switch/case statement somewhere in the object logic and a plethora of handle_incoming_type_asdf functions for each Activity(Object) variation supported.
The network request point is kinda moot, as you would want to derefence (and fetch) the Object most of the times anyway. At least for me it’s about developer experience (clarity), getting rid of JSON-LD while still getting some validation and removing possible semantics conflicts between FEPs and/or different extensions. The last is solved by LD, but I want to get rid of it instead. As a bonus, instances not supporting the extensions will drop it early instead of making requests only to drop the Activity in the end.