@evan by which i mean: i'd go even further and say that activitypub servers should store-and-forward anything that has as:to/cc/audience. and as:actor so you know it's an activity.
Top-level
@evan by which i mean: i'd go even further and say that activitypub servers should store-and-forward anything that has as:to/cc/audience. and as:actor so you know it's an activity. 3 comments
@evan whatever the mechanism i do think isActivity() needs to be specified within mainline AP. i know we have a primer page but having it in-spec would be really useful too. something similar for allowing Actor to be declared on objects with ldp:inbox and as:outbox could also be useful if we *really* wanna avoid duck-typing. although i am not as opposed to duck-typing as you are… the definition of as:Actor would specifically be “my ldp:inbox dereferences to a Collection of Activity or subtype” @evan in other words if something is an Actor then it is expected that you can send Activity notifications to it as opposed to generic LDN, and crucially, ***it will handle those activities with side-effects defined in activitypub*** it therefore may also make sense to define Actor and isActor() at the spec level |
@trwnh I'm with you, although I think extensions should use multi-typing to indicate that it's an activity (`"type": ["myns:Foo", "Activity"]`)