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

Also available at
https://socialhub.activitypub.rocks/t/boundaries-between-ap-and-as2-and-between-as2-and-non-as2/8681

Context:
- https://github.com/w3c/activitystreams/issues/595
- https://lists.w3.org/Archives/Public/public-swicg/2026May/0015.html
- https://lists.w3.org/Archives/Public/public-socialweb/2026May/0001.html

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="https://www.w3.org/ns/activitystreams", 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="https://www.w3.org/ns/activitystreams" 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:

- https://github.com/w3c/activitystreams/issues/718 notes that AS2
documents don't have a default processing model, although we could
define one or more such processing models.
- https://github.com/w3c/activitystreams/issues/724 notes that
fetching additional information is left unspecified -- for https: ids
we can gather that the HTTPS protocol can be used to issue an HTTP
GET, as described in AP Section 3.2. But it might make a lot of sense
to recommend that AS2 documents are relatively self-contained, and
that publishers should include enough useful information without
requiring consumers to fetch additional information. However, it might
be useful or necessary to fetch additional information (similar to how
many HTML browsers will also fetch rel=stylesheet links on behalf of
their users).
- https://github.com/w3c/activitystreams/issues/726 notes that content
negotiation can affect the returned representation that you might try
to fetch per issue 724. Neither JSON-LD nor the World Wide Web require
referenced resources to have any particular/specific Content-Type, and
so if AS2 or AP is to place such a requirement, then it's unclear
where it would be placed or how it would be made feasible.

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.

https://datatracker.ietf.org/doc/html/rfc8288 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.

Received on Tuesday, 12 May 2026 03:26:03 UTC