a

Also available at: https://lists.w3.org/Archives/Public/public-swicg/2026May/0017.htmlhttps://lists.w3.org/Archives/Public/public-socialweb/2026May/0002.html Context: https://github.com/w3c/activitystreams/issues/595https://lists.w3.org/Archives/Public/public-swicg/2026May/0015.htmlhttps://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.

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 that other instance. (Say you knew of an "instance actor" that linked to its "users" collection.) If you used relative identifiers and implicitly expand them against the current network location, it could look like this: { "@context": [ "@base": "https://funkwhale.example/", // insert your own instance name here "https://www.w3.org/ns/activitystreams" ], "audience": "/users/" // only you need to know what this means, so there aren't any compatibility/interop concerns} If you used absolute identifiers it would look like this: { "@context": "https://www.w3.org/ns/activitystreams", "audience": "https://funkwhale.example/users/"} --- petitminion: If a project do not implement Artist or some other objects they can still parse the audio metadata and use it has they wish. They just can’t share the metadata that is missing an id. Would it be correct to interpret this as Funkwhale allowing anonymous objects? (Fudging the vocab here a bit): { "@context": "https://www.w3.org/ns/activitystreams", "actor": { "name": "a" }, "type": "Listen", "object": { "name": "House of Leaves", "attributedTo": { "name": "Circa Survive" } }} You could specify any "id" here to enable reuse, but on its own, this document contains enough information to describe a useful activity: a listened to "House of Leaves" by Circa Survive. You could progressively enhance this with other statements, like when the Listen occurred, or so on. You just don't know which specific we're talking about here, although you can probably be reasonably sure you know what is meant by and by context clues -- specifically, that since this is a Listen activity, the Listen.object is probably some listenable thing like a Track, and then a Track.attributedTo is probably the attribution of a Track to an Artist, and then you fill in the gaps that way to understand that we are both talking about the band Circa Survive and their work "House of Leaves". This is all known as "identity by description", as opposed to "identity by name" which is a thing you can do to enable easier reuse. (The third way to identify something is "identity by possession". If this sounds familiar at all, it's because they map to the concept of "authentication factors" -- "what you know", "what you are", and "what you have".) --- petitminion: We should describe a mechanism to get the Audio object if we only have a Track Couldn't you just link Audio objects to the Track? Or the other way around could work, too. For Funkwhale this is like saying: I have a Library containing an Audio, and the Audio references a Track; orI have a Track referencing an Audio contained in a Library. I assume Funkwhale doesn't store an index of which Tracks correspond to which Audio objects (since what I have seen so far without looking deeply is that Funkwhale prefers to index Audio objects that individually refer to a Track), but it's doable. It would also allow searching for a Track and finding any Library that contains an Audio object referencing that Track ("which libraries contain audio for this track" rather than "which track does this audio represent"). I think this is what you mean by this bit? petitminion: add an Audio attribute to the Track object --- petitminion: An issue arise when the source instance goes down : we should probably have a mechanism that allow another instance to “claim the responsibility” of the track metadata ? This seem impossible since ids can’t changes… The "responsibility" is implicitly tied to the id. If you have a "metadata provider" then you can notify them of any new Audio objects referencing it (which is I think what you are proposing with the "source of the track" stuff described above?). { "type": "Activity", "summary": "Letting you know that your Track was uploaded as Audio", "audience": "https://track-owner.example/", "object": "https://audio.example"} petitminion: Another option is to use musicbrainz : give them the audio id has streaming link (its a centralized approach but why not) If you're using Musicbrainz to provide Track metadata then why not use their database directly? Otherwise, you could link a metadata provider's data by declaring it as being equivalent to the Musicbrainz entities. { "@id": "https://musicbrainz.org/work/38df7f57-de90-437f-8a61-3dd8f4e2f9af"} Although this does raise the issue of what to do when the metadata of the Audio doesn't actually match the metadata provider's information. For example, according to Musicbrainz, the Recording is https://musicbrainz.org/recording/7a3fad60-938e-4c17-bc83-342acd713c04 "Meet Me In Montauk", which contains the titular work followed by ~7 minutes of silence, and then the hidden "bonus track" follows afterward. In my personal library, the audio I'm playing has actually been extracted from the official release, so that my copy of "Meet Me In Montauk" is only about 2 minutes long instead of 14:39, and my copy of "House of Leaves" represents something that was never officially released as a singular Track. If we take the activity from before, then the question is this: what did I actually listen to? I didn't listen to "Meet Me In Montauk".I didn't listen to the 7 minutes of silence.I listened to "House of Leaves".What I listened to is not described in Musicbrainz as a Recording.It is described by Musicbrainz as a Work (specifically a Song). What ends up in the Funkwhale concept of a "Track"? Which musicbrainzId do you use? Does it get an id?

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?

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.

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 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" } }}