Restricting Activity Streams Documents to Object and subtypes

[evanp]

In Section 2:

An Activity Streams Document is a JSON document whose root value is an Activity Streams Object of any type, including a Collection, and whose MIME media type is " application/activity+json".

"JSON document" and "root value" here might need to be better tied to RFC 8259, which uses the term "JSON text".

It would be good to have an idea of what an "Object of any type" might mean. Is this a JSON object with a "type" property that includes Object or any of its subtypes? Should we note multityping here? Maybe we should refer to the type hierarchy.

Since Object and Link are disjoint, this means that a Link or its subtypes (Mention, Hashtag) as a top-level object would not be an AS Document.

[trwnh]

Hmm, I'm wondering if there is a good reason to say that a document with a root node where the type is a Link shouldn't be considered an AS2 document.

There are some things we have to watch out for here as well:

• type is not a required property
• something can be inferred to be an as:Object if it uses any of the properties of an as:Object

[cristianolongoodhl]

Object of any type in the sense that it is a subclass of Object (yes, referring to the class hierarchy is nice). And yes, a link is not an Activity Stream document, in the sense that it should not be sent alone to agent inboxes. Of course, a link or other items could be embedded or referenced inside an Activity Stream document. Concerning "JSON text", honestly I don't have enough knowledge about JSON to provide my own opinion.

[evanp]

I can live with having an ASD only be Object or subtypes, but I think we should at least say why.

[cristianolongoodhl]

In my understanding, an activity stream document is something which can be exchanged by actors. Considering the format name, I would further restrict to Activities.

[trwnh]

@cristianolongoodhl Having Activity Streams 2.0 Documents represent either "activities" or "streams" sounds appealing, but it isn't valid because an AS2 document can also be any Object, such as a Person or an Article. Requiring documents to contain either activities or streams would not only be a breaking change, but it would also effectively force all non-activities or non-streams to be embedded into the representation of activities and/or streams (since you wouldn't be able to reliably obtain more information by dereferencing an AS2 document from the id).

With that said: someone could derive a profile or protocol based on actors having a media type like application/cid instead of application/activity+json. But doing so would need you to define when to request resources as application/activity+json and when to request them as application/cid. Maybe you could say Accept: application/activity+json, application/cid+json? I dunno, this is theorycrafting at this stage and unlikely to result in widespread adoption before 2026 ends. For AS2's purposes right now, we say that an AS2 document is not a Link.

[cristianolongoodhl]

@trwnh following the linked data principles, every resource should be deferenceable, so that you should be capable of getting the json-ld of any item, also if they are links or persons. However, this is not about the distribution of activity streams. I suppose that the original idea behind this format were that when a new actor arise, a create activity concerning it is distributed all over the federated network. Of course right now the actual situation may be different.

[trwnh]

Yes you can dereference resources but the representation you get might not

be understood. For example say you dereference an actor and get an HTML representation because an AS2 representation wasn't available.

…

Message ID: ***@***.***>