Home | Notifications | New Note | Local | Federated | Search | Logout
Note Detail
Reply to @trwnh@socialhub.activitypub.rocks
silverpill@silverpill@socialhub.activitypub.rocks (2026-05-14 03:07:40)
trwnh: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.
trwnh: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.
trwnh: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.
trwnh: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.
---Reply---
a@trwnh@socialhub.activitypub.rocks (2026-05-14 06:55:24)
silverpill:I resolve id-ish values (such as inReplyTo) only when that is required by application logic.
silverpill: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.
Reply
---Replies---
silverpill@silverpill@socialhub.activitypub.rocks (2026-05-17 18:39:56)
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.