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

Every id value is expected to be an identifier of an ActivityPub object. When it resolves to something else, like an HTML document, we conclude that the identifier is not valid.

Fediverse != Web

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.

@hongminhee So, Fedify returns a string and delegates the decision to the user?

Sounds reasonable. By default, hrefs do not point to ActivityPub objects.

Also available at:

• https://lists.w3.org/Archives/Public/public-swicg/2026May/0017.html
• https://lists.w3.org/Archives/Public/public-socialweb/2026May/0002.html

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.

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

It difficult to answer because there are different mental models of AS2:

• JSON documents (constrained to look like JSON-LD, but not actually meant to be JSON-LD)
• JSON-LD serialization of RDF subgraphs (for communication, storage and other purposes).
• Some kind of HTML-ish/WWW document
• …

If AS2 is serialized RDF then a “link” is an edge in the RDF graph. A JSON-LD “direct link” just means the RDF object was not embedded in a specific subgraph serialization. Note that, even if the RDF object is embedded in the serialization, there’s still a link when the representation is deserialized back to RDF.

I agree that an AS2 link, in this RDF sense, is not required to refer to resources with a specific media type. In other words, they are not required to only reference AS2 documents.

(Side note: from this perspective, as:Link is a reified “link” or relationship. The as:Link objects’s href property should be an @id, because it’s a reference to a resource. See also: When use a literal for a URI in Linked Data)

If AS2 is considered to be plain JSON, then the meaning of “link” becomes relatively muddled for me. It’s even more muddled if one interprets AS2 as HTML rather than Linked Data. Note that AS2 can be used in ways that have no relationship to the HTML/HTTP Web. Although the AS2 spec describes as:Link as being closely related to the concepts in RFC5988, “closely related” means “somewhat different”. However, the differences are not clearly described so this just leads to more confusion IMO.

there are different mental models of AS2 If AS2 is considered to be plain JSON, then the meaning of “link” becomes relatively muddled for me

Yeah -- even for people who understand the difference between a direct link and an indirect/reified Link, there's still uncertainty about when you would want to use one or the other. "You can describe properties of the link/reference" is something that makes sense in the abstract but it depends on a processing model to make sense in practice. as:Link feels like it's largely unused in AS2 documents across the fediverse; most links are direct links by way of using AS2 properties with non-embedded objects. (For example, when "actor" and "object" are JSON strings instead of as:Link nodes.)

Every id value is expected to be an identifier of an ActivityPub object. When it resolves to something else, like an HTML document, we conclude that the identifier is not valid.

• Do you expect every AS2 document to be an ActivityPub object?
• Do you dereference every id to make sure of what it resolves to?
• If some id doesn't have an AS2 representation, do you:
  • ...discard the entire activity?
  • ...discard that particular statement?
  • ...process the statement as-is without further information?

Fediverse != Web

One can certainly claim this (and they might not be fully incorrect per se), but then it leads to asking if AP == AS2 == Fediverse, or if AP == Web != Fediverse != AS2. At least in theory, AP and AS2 are intended to be Web specifications published by the W3C under the Social Web WG.

By default, hrefs do not point to ActivityPub objects.

Would you then say something like this?

• If an id is the "href" of a Link, then it can have representations not including AS2.
• Otherwise, an id (SHOULD? MUST? MAY? is expected to without being required to?) have an AS2 representation.

We currently don't require this, and there is no processing model defined for AS2 documents. AP implies a partial processing model that includes retrieving objects via their id, but this is only for AP, and it only applies when the id is an object id. So you could read it as applying to this:

{ "actor": {"id": "https://alice.example/#alice", "type": "Person"}}

But maybe not this (unless you somehow infer this is an Object, which by default can't be done while the range of "actor" is Object | Link):

{ "actor": "https://alice.example/#alice"}

And maybe not this either (unless you assume the "href" is an object):

{ "actor": { "url": { "href": "https://alice.example/#alice" } }}

there are different mental models of AS2 If AS2 is considered to be plain JSON, then the meaning of “link” becomes relatively muddled for me

Yeah -- even for people who understand the difference between a direct link and an indirect/reified Link, there's still uncertainty about when you would want to use one or the other. "You can describe properties of the link/reference" is something that makes sense in the abstract but it depends on a processing model to make sense in practice. as:Link feels like it's largely unused in AS2 documents across the fediverse; most links are direct links by way of using AS2 properties with non-embedded objects. (For example, when "actor" and "object" are JSON strings instead of as:Link nodes.)

Every id value is expected to be an identifier of an ActivityPub object. When it resolves to something else, like an HTML document, we conclude that the identifier is not valid.

• Do you expect every AS2 document to be an ActivityPub object?
• Do you dereference every id to make sure of what it resolves to?
• If some id doesn't have an AS2 representation, do you:
  • ...discard the entire activity?
  • ...discard that particular statement?
  • ...process the statement as-is without further information?

Fediverse != Web

One can certainly claim this (and they might not be fully incorrect per se), but then it leads to asking if AP == AS2 == Fediverse, or if AP == Web != Fediverse != AS2. At least in theory, AP and AS2 are intended to be Web specifications published by the W3C under the Social Web WG.

By default, hrefs do not point to ActivityPub objects.

Would you then say something like this?

• If an id is the "href" of a Link, then it can have representations not including AS2.
• Otherwise, an id (SHOULD? MUST? MAY? is expected to without being required to?) have an AS2 representation.

We currently don't require this, and there is no processing model defined for AS2 documents. AP implies a partial processing model that includes retrieving objects via their id, but this is only for AP, and it only applies when the id is an object id. So you could read it as applying to this:

{ "actor": {"id": "https://alice.example/#alice", "type": "Person"}}

But maybe not this (unless you somehow infer this is an Object, which by default can't be done while the range of "actor" is Object | Link):

{ "actor": "https://alice.example/#alice"}

And maybe not this either (unless you assume the "href" is an object):

{ "actor": { "url": { "href": "https://alice.example/#alice" } }}

At least in theory, AP and AS2 are intended to be Web protocols published by the W3C under the Social Web WG.

I don’t believe that AS2 is, or was intended to be, a protocol. The spec describes the goal was to…

provide a JSON-based syntax that is sufficient to express metadata about activities in a rich, human-friendly but machine-processable and extensible manner. This can include constructing natural-language descriptions or visual representations about the activity, associating actionable information with various types of objects, communicating or recording activity logs, or delegation of potential actions to other applications.

For me, syntax != protocol.

there is no processing model defined for AS2 documents.

Although it’s impossible to know without defining “processing model”, I think this is a dubious claim. There’s the JSON-LD processing model and, in a Linked Data context, there’s the RDF processing model. It’s very possible that those models are not sufficient for Fediverse/AP purposes, but that’s a different claim than that there’s processing model at all.

EDIT: Just saw this in the AS2 spec:

this specification does not define a normative processing model that constrains how applications make use of the format, the distinction about whether an Activity statement is to be interpreted as a passive notification or as an imperative command can vary across implementations.

So, if by “processing model”, you mean “application processing model”, then I understand the original claim. However, I wouldn’t expect AS2 to define application-specific processing models.

Also, what do you mean by “boundaries” in this discussion. I can’t determine if you are asking about what objects should be embedded or not in AS2 serializations (the “boundary” of a serialized subgraph that’s then published using AP) or is “boundary” the links between AS2 objects and/or other resources. Or both? Or something else?

Do you expect every AS2 document to be an ActivityPub object?

Yes. I don't think of AP and AS2 as separate things, and in my view, any contradictions between the two are specification bugs.

Do you dereference every id to make sure of what it resolves to?

No, that would be impractical. I resolve id values only when an object needs to be authenticated (for example, when it is not signed). I resolve id-ish values (such as inReplyTo) only when that is required by application logic.

If some id doesn’t have an AS2 representation, do you:

• …discard the entire activity?
• …discard that particular statement?
• …process the statement as-is without further information?

In most cases, the entire activity is discarded. An activity is not very useful if you can't authenticate it or resolve its actor. But sometimes only a particular statement is discarded.

Would you then say something like this?

• If an id is the “href” of a Link, then it can have representations not including AS2.
• Otherwise, an id (SHOULD? MUST? MAY? is expected to without being required to?) have an AS2 representation.

How href can be an id? What I mean is that in JSON-verse, href is not considered an id-ish property. FEP-e232 is an exception to this rule.

I resolve id-ish values (such as inReplyTo) only when that is required by application logic.

What I mean is that in JSON-verse, href is not considered an id-ish property. FEP-e232 is an exception to this rule.

I'm mainly talking about what you call "id-ish" -- when a property has a value that is a JSON string interpreted as a reference (@type: @id in the context).

It sounds like you don't try to fetch those unless needed, which is good; I'm still not sure what your criteria for "needed" would be, though.

So for example, with a document like this:

{ "inReplyTo": "https://apnews.com/article/reading-math-test-scores-education-scorecard-7fa4111ad0de934f664ebb984e830d13"}

I imagine you would attempt to fetch the replied-to resource, fail to find an AS2 representation, and treat the currently-processing object as having a broken reply link (even if there are non-AS2 representations for the replied-to resource).

With a document like this:

{ "type": "Article", "url": { "href": "https://apnews.com/article/reading-math-test-scores-education-scorecard-7fa4111ad0de934f664ebb984e830d13" }}

I imagine you would leave it up to the user whether they want to follow that link or not.

And for a document like this:

{ "tag": { "href": "https://apnews.com/article/reading-math-test-scores-education-scorecard-7fa4111ad0de934f664ebb984e830d13", "mediaType": "application/ld+json; profile=\"https://www.w3.org/ns/activitystreams\"" }}

I imagine you would take that as a hint to fetch the "href" with Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams", but if you instead encountered this document:

{ "tag": { "href": "https://apnews.com/article/reading-math-test-scores-education-scorecard-7fa4111ad0de934f664ebb984e830d13" }}

Then I imagine you'd go back to letting the user decide whether to fetch it... or possibly ignore it, or possibly some other application-specific thing.

This is probably how things would work if I were to develop a high-level library similar to Fedify.

But I built APx, a low-level library. It is only aware of several special properties, such as id (which is used to authenticate fetched objects) and proof (which is used to verify FEP-8b32 signatures). The user decides what to do with other properties.

Mitra, on the other hand, attempts to follow inReplyTo and FEP-e232 references when it processes an object, but only because it cares about "posts". There are no general rules for id-ish properties and hrefs.

But do you distinguish between "id" as a property vs an id as a property's value? Do you authenticate one but not the other? And if there isn't an AS2 representation do you conclude it's not authentic somehow?