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

út 12. 5. 2026 v 5:27 odesílatel a <a@trwnh.com> napsal:

> 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.
>

The name/locator split in RFC 3986 may already cover much of this. AS2
places no constraint on the scheme used for an id, and AP S3.2 only
specifies behavior for the dereferenceable case, so a publisher who wants a
stable identifier without committing to an AS2 representation already has a
standards-conformant option in URNs (RFC 8141). This doesn't challenge the
linked data ideal; dereferencing for richer information remains valuable
wherever publishers can offer it. The point is that https: carries an
implicit "fetch me" affordance where URNs do not, and AS2 already permits
both. As one concrete on-ramp, urn:solid: ( https://urn-solid.com/ )
registers common RDF terms, including most AP/AS2 vocabulary, as URNs, and
can be upgraded to a hosted vocabulary later via owl:sameAs or a JSON-LD
context without rewriting data. A name-shaped tool when you need a name, a
locator-shaped tool when you need a locator.