Home | Notifications | New Note | Local | Federated | Search | Logout
a@trwnh@socialhub.activitypub.rocks
Joined: 2026-05-12 23:15:40
5 notes, 0 following, 0 followers
Reply to @silverpill@socialhub.activitypub.rocks
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?
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 to @stevebate@socialhub.activitypub.rocks
a@trwnh@socialhub.activitypub.rocks (2026-05-13 05:53:50)
stevebate: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.)
silverpill: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?
silverpill: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.
silverpill: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 mo
a@trwnh@socialhub.activitypub.rocks (2026-05-12 12:29:34)
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 "c
Reply to @silverpill@mitra.social
a@trwnh@socialhub.activitypub.rocks (2026-05-06 09:05:50)
silverpill:single-word strings, not URIs
slight pushback on the "not URIs" bit -- even JSON strings that aren't in normal form are still identifiers because "audience" is defined in a way that types its values as identifiers. it could be disambiguated by expanding those (in effect relative) identifiers against a base URI, but you can't make this part of the definition of "audience" without confusing others who don't share this definition. and "audience" is also already defined by AS2 which requires that you MUST NOT override or change its definitions. I think the earlier recommendation to map these to existing identifiers still holds: https://socialhub.activitypub.rocks/t/fep-be68-audio-objects/8614/10
---
petitminion:Why not use this approach then. For the instance why no use the instance url ? This would also allow to share activities with one specific instance and not with others ?
This is fine as long as everyone agrees on what the "instance URL" is. The service itself isn't necessarily always represented by the HTTP resource /. I think for the Funkwhale concept of instance you could mint an identifier like https://funkwhale.example/users/ and have it represent all users on the host funkwhale.example. You could then describe that as a Collection, as well:
{ "@context": "https://www.w3.org/ns/activitystreams", "id": "https://funkwhale.example/users/", "type": "Collection", "name": "funkwhale.example's users" "summary": "Represents every user on funkwhale.example"}
and then another-funkwhale.example would have its own users:
{ "@context": "https://www.w3.org/ns/activitystreams", "id": "https://another-funkwhale.example/users/", "type": "Collection", "name": "another-funkwhale.example's users" "summary": "Represents every user on another-funkwhale.example"}
Your local instance should know its own local users collection ID. If you knew the collection ID of another instance's users, you could in theory send them activities that would be forwarded (or not) by t