Boundaries between AP and AS2, and between AS2 and non-AS2

ActivityPub
1

Also available at:

Context:

In earlier discussion regarding how people expect a Link to work, it seems to me like we uncovered a sort of X-Y issue. Hong Minhee, who develops the Fedify library, indicated that overriding the term definition of “href” to be a literal string instead of a URI reference was intended to avoid dereferencing ids that don’t have AS2 representations. The inherent assumption is that any id will have an AS2 representation, but this isn’t a valid assumption, because non-AS2 resources exist on the Web (and in fact vastly outnumber AS2 resources).

Across the specification documents for AS2-Core, AS2-Vocab, and AP, the only remotely relevant language I could find was in AP Section 3.2 “Retrieving objects”:

The HTTP GET method may be dereferenced against an object’s id property to retrieve the activity. Servers MAY use HTTP content negotiation as defined in [RFC7231] to select the type of data to return in response to a request, but MUST present the ActivityStreams object representation in response to application/ld+json; profile=“ActivityStreams 2.0 Terms”, and SHOULD also present the ActivityStreams representation in response to application/activity+json as well. The client MUST specify an Accept header with the application/ld+json; profile=“ActivityStreams 2.0 Terms” media type in order to retrieve the activity. Servers MAY implement other behavior for requests which do not comply with the above requirement

From this, we can see that there is no explicit requirement for every id in an AS2 document to be dereferenceable with an AS2 representation. At most, we can say that ActivityPub requires “clients” to use an Accept header, and “servers” MUST/SHOULD present the AS2 representation when they see this Accept header. But publishers of AS2 documents or AP activities are not required to only use ids of resources necessarily bearing an AS2 representation. I don’t think this is something we can feasibly require, either, as doing so effectively amounts to forking the Web.

Recently, I filed some issues against AS2 regarding these uncertainties:

Previously, https://w3id.org/fep/e232 proposed “object links” as a potential way to reduce this ambiguity, under the assumption that a Link.mediaType could not only hint that a representation existed for a certain Content-Type, but that you could (or should?) also use this hint with an Accept header in order to obtain that representation with a specific Content-Type.

RFC 8288 - Web Linking notes several times that attributes of links are only hints – they do not guarantee a representation exists, and they do not tell you whether content negotiation is needed.

Therefore, I would like to expand my previous question, and invite further discussion about the larger issue. It’s not simply about whether anyone uses (or doesn’t use) the as:Link class anymore; there is a much more fundamental issue about how any link is expected to be used, even (or especially) direct linked data references as are present everywhere in an AS2 document.