silverpill@silverpill@socialhub.activitypub.rocks: This is probably how things would work if I were t…

Home | Notifications | New Note | Local | Federated | Search | Logout

Note Detail

Reply to @silverpill@socialhub.activitypub.rocks
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---
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.


---Replies---

a@trwnh@socialhub.activitypub.rocks (2026-05-18 09:46:29)
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?