@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.
@benpate@activitypub.space @technical-discussion@activitypub.space @julian@activitypub.space The point @silverpill@mitra.social 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,...
@julian@activitypub.space @technical-discussion@activitypub.space @silverpill@mitra.social The point is getting rid of JSON-LD while still getting pseudo-namespaces.
If you wanna use JSON-LD to verify those semantics, you are free to do so, but that is entirely optional.
@silverpill@mitra.social @technical-discussion@activitypub.space @benpate@activitypub.space If you are going through the trouble of using your own vocabulary, why not at least make it so that namespace conflicts don't ever happen again, similarly like they do with semantics using AS Vocab now.
If you implement OfferEndorsement and I want to use it as well, but for something incompatible with your thing. Then I guess I need to invent a new less descriptive name for my thing like: NewAPServerOfferEndorsement, if you effectively reserve that name for your thing and depend on that name being unique for handling.
So I think, something like below is a better solution to the same problem, while admittedly looking worse:
@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.
@benpate@activitypub.space @technical-discussion@activitypub.space @julian@activitypub.space The point @silverpill@mitra.social 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,...
@julian@activitypub.space @technical-discussion@activitypub.space @silverpill@mitra.social The point is getting rid of JSON-LD while still getting pseudo-namespaces.
If you wanna use JSON-LD to verify those semantics, you are free to do so, but that is entirely optional.
@silverpill@mitra.social @technical-discussion@activitypub.space @benpate@activitypub.space If you are going through the trouble of using your own vocabulary, why not at least make it so that namespace conflicts don't ever happen again, similarly like they do with semantics using AS Vocab now.
If you implement
OfferEndorsementand I want to use it as well, but for something incompatible with your thing. Then I guess I need to invent a new less descriptive name for my thing like:NewAPServerOfferEndorsement, if you effectively reserve that name for your thing and depend on that name being unique for handling.So I think, something like below is a better solution to the same problem, while admittedly looking worse:
fep-3447:OfferEndorsementfep-3447:AcceptEndorsementfep-3447:RejectEndorsementfep-3447:UndoEndorsementOr
fep-3447:Offerfep-3447:Acceptfep-3447:Rejectfep-3447:Undo