Formally define "activity" at the spec level

[trwnh]

Define "activity"

This is primarily relevant for C2S "Create without activity" flow, but can be useful in other contexts.

There is a gap identified where extensions that are sub-types of Activity need to be identifiable as activities. There are two main ways to do this:

1) Explicitly multi-type it as as:Activity 2) Duck-type it based on presence of properties like as:actor 3) (If an ontology definition is available): Check the class hierarchy to see if the given class inherits from as:Activity

We have https://www.w3.org/wiki/Activity_Streams/Primer/Identifying_Activity_Objects over in the AS2 primer that mostly states exactly this, but it should also be mentioned in the AP primer in context of C2S POST to outbox without wrapping Create activity, at minimum. Ideally, it would also be mentioned in the spec, perhaps by defining or clearly writing out some algorithm for processing what to do when a POST is received to the outbox. This explicit "algorithm" section is also more generally useful for anyone wanting to implement AP C2S. (For example, other specifications such as JSON-LD provide their algorithms for implementers to follow.)

[evanp]

Moving the actor question to a separate ticket.

[evanp]

I think this makes sense. Let's mark it as Next Version, and we'll consider it when we open up the Working Group.

[nightpool]

So the question here is "In a C2S Create flow, how do we identify whether an object is an Activity if it's a subtype the server doesn't recognize?". That makes sense, but I wonder if it isn't maybe putting the cart before the horse a bit. I think it's completely reasonable to specify that Create Without Activity only works for the base (non-extension) Object types, and not worry about identifying Activities at all. It's such a minor DX feature that I'm not really sure it's worth worrying about.

[trwnh]

yeah this is mostly relevant to "C2S Create without wrapping Create".

if the solution or assumption is "this only works for native non-activity object types" then that should be explicitly stated in the spec section 6.2.1

here's some user stories:

• "as a user, i want to know that when i POST to my outbox, my server will not mistakenly wrap it in a Create and ruin whatever semantics i intended"
• "as a server/developer, i want to know explicitly whether i should wrap this thing i don't recognize in a Create or if i should deliver it as-is"

right now the flow in 6.2.1 creates ambiguity for anyone who wants to POST a document that isn't one of the native AS2 Activity types.

if the solution is "deliver everything as-is unless it's an AS2-Vocab non-activity object type", then i guess that could work but it assumes that every extension is implicitly an Activity. which it might not be!

[nightpool]

I agree that we should state it explicitly but in my mind 6.2.1 is a "nice-to-have" that doesn't really benefit from all the extra formalism this issue proposes. I'd also be okay with deprecating 6.2.1 entirely, I just think it's nice to have when writing e.g. small share buttons or other clients that don't need to worry about nested activities.

if the solution is "deliver everything as-is unless it's an AS2-Vocab non-activity object type", then i guess that could work but it assumes that every extension is implicitly an Activity. which it might not be!

Definitely not true! It just assumes that if you're using an extension, you need to wrap it in a Create yourself. Like any other non-Create activity.

[trwnh]

in my mind 6.2.1 is a "nice-to-have"

so do we deprecate 6.2.1 entirely, then? because i think it actually is useful for the things you describe and more, but right now the problem is that it creates ambiguity where there would otherwise be none.

like, in an LDN situation, you can send whatever you want to the ldp:inbox. it doesn't have to be an activity. in an AP situation, the requirement is that you are specifically sending an Activity. but the as:outbox doesn't have a single unambiguous way of enforcing or even knowing that what you've posted fits that requirement. the 6.2.1 behavior feels like it exists to coerce everything into the shape of an Activity. this breaks down when dealing with extensions because you don't know whether it is an activity or not, so you don't know whether it should be coerced or not.

[nightpool]

I don't think deprecating 6.2.1 entirely is necessary—just state explicitly that it doesn't work for extension types. I don't really see any downside to that.

[trwnh]

this is taking the mechanism away from extension types entirely though.

[nightpool]

what would be the benefit of using it with extension types? if you're using extension types anyway you might as well specify the Create yourself.