It’s not mandatory per FEP-e232, but I think it’s reasonable to expect that some implementations may ignore object links that are not explicitly marked as quotes.
I will probably use rel: https://misskey-hub.net/ns#_misskey_quote for that purpose, but my implementation will continue to accept any object link where link target looks like a post, with rel or without.
In our case it’s fine if they ignore it, because the included content is already present in the activity content field. We don’t actually need it. It’s just a hint to those platforms which aggressively filter HTML; although these are typically the same platforms that reject quoted posts, so they’re probably going to reject it anyway.
While the FEP describes a method for linking between objects, it is silent on the subject of linking to parts or fragments of objects. However, it seems to me that a user’s intent in linking to an object is often to draw attention to some part or fragment of that object, not to the entire object. In order to express such an intent, it is necessary to have a means to provide fragment selectors in addition to or as part of URIs.
Is the FEP’s silence on the subject of fragment selectors intentional? Is support for fragment selectors implied since they are part of the URI syntax? Is there some reason why links to fragments would not be supported or desired?
The W3C Annotations standard describes a method for linking between objects, but, unlike this FEP, it explicitly defines or recognizes a wide variety of media-type or use-case specific fragment selectors. It seems to me that it would be appropriate to explicitly support or acknowledge the use of a similarly rich variety of fragment selection methods in this and similar FEPs.
Below are links to the sections of the Annotation spec that discuss the fragment selectors that are explicitly recognized. It seems to me that support for all of these would be reasonable for at least some useful subset of use cases. Of course, explicit support for them would not always be a requirement. Simple implementations would handle URI-embedded selectors opaquely and, for selectors not embedded in the URI, would default to the base URIs.
The use case of linking to specific parts / fragments was not considered when this proposal was written, and since this proposal is on its way to finalization, I feel that we shouldn’t expand its scope. Perhaps fragments can be covered by another FEP, which builds upon this one?
The motivating use-case of this FEP was “this Link can be fetched via ActivityPub”, which is useful information for knowing whether to load the link in-app or in an external browser. No other use-cases were considered or ignored, either intentionally or unintentionally. The FEP can be summed up almost entirely by its use of the required ActivityPub Accept header within mediaType.
Tangentially, there is the possibility of using the name as a microsyntax, and the rel to establish semantics via link relations, and these two things together have been used by e.g. Foundkey to identify “Misskey quotes” or “Fedibird quote URIs” within the body of the content, associating the RE: <url> microsyntax with the object link to the “quoted” status.
The idea of linking to fragments is something that can exist outside of this FEP, either in HTML content as an <a> tag, or in metadata as a Link in tag. It could be interesting to see support for this, but I do not see a way to refer to arbitrary JSON-LD or a subset of some property’s value. This is something that someone else will have to figure out in a separate FEP or similar effort.
Was there a reason that the ld+json profile refers to the whole activity streams namespace, and not a particular element? It seems like that would help to indicate to receiving apps not only that the resource is an AS object, but also which kind. That would help to decide whether they should even bother trying to open it in the app, based on their implementation.
So that would look like "mediaType": "application/ld+json; profile=\"https://www.w3.org/ns/activitystreams#Note\"" or "mediaType": "application/ld+json; profile=\"https://www.w3.org/ns/activitystreams#Image\""
Sorry if this has been discussed, I know I’m late to this party. I searched through the thread and didn’t see anything like this mentioned.
POST requests (eg. to the inbox) MUST be made with a Content-Type of application/ld+json; profile="https://www.w3.org/ns/activitystreams" and GET requests (see also 3.2 Retrieving objects) with an Accept header of application/ld+json; profile="https://www.w3.org/ns/activitystreams".
The profile parameter is for the JSON-LD processing profile. Other profiles of JSON-LD include “expanded”, “compacted”, “flattened”, and so on.
The exact vocabulary supported by any implementation is generally declared in the @context element.
mediaType is slightly unusual in that it is defined both as an element of Object and also of Link. These two properties are ‘disjoint’ with each other, but mediaType, name, and preview are used in both. It is not specifically a property of ‘Note’ or ‘Image’.
The activitystreams profile is usually only required for accessing activitystreams content using the ActivityPub protocol. There are other protocols which generate and consume ActivityStreams which may use different profiles or Accept headers.
I doubt these profile links would be allowed by IANA, see here and then here to find:
Other specifications may publish additional profile parameter URIs
with their own defined semantics. This includes the ability to
associate a file extension with a profile parameter.
My understanding is then that this comes into play. I’m somewhat confused by it now, as I cannot see that the used profile parameter is published.
So to answer your question: I don’t think adding a hashtag in the profile is covered by the current IANA submissions, and I’m not sure that the currently used profile is either. So it’s best to use “application/activity+json”.
activitypub overrides as2-core in its preference for media type. it mandates you MUST use ld/json with the activitystreams profile when sending or fetching, and if fetched with ld/json and that profile, you MUST respond. you SHOULD handle the as2-specific activity+json as well, but this is not required. this is because between 2014 and 2018, the debate around media type reached the conclusion that they wanted to support generic LD consumers as well.
I think there should be a separate FEP describing the recommended FEP-e232-based representation of a quote. FEP-e232 only provides a generic framework for building object links, and IMO shouldn’t be concerned with specific use cases (maybe a quote example should be replaced with something else?).
As far as I can tell, there are two possible ways to do quote:
type: Link with rel: https://misskey-hub.net/ns#_misskey_quote
type: Quote without rel.
Per FEP-e232, both are allowed. The second one is simpler because implementer only needs to check for type property. However, the Quote type should be defined somewhere and we still don’t have a way to do that for FEPs (FEP-888d?).
this could make sense in an FEP that defines a separate quotes collection perhaps? although care is needed to not make it awkward. for example the shares collection is straightforward due to the use of Announce activities, but the replies collection is less straightforward due to the passive nature of discovering replies based on inReplyTo usually not on the activity itself but on the object of the activity. so having a quotes collection would require yet another layer in the algorithmic onion, in filtering the tag array on any discovered object.
alternatively: the Quote could be a microsyntax like Mention (or Hashtag or Emoji), which could facilitate “you’ve been quoted” type notifications perhaps. but yes, this is something that would be best tackled in its own FEP.
that’s one way to do it. i think the other way to do it is to just use whatever long-lived domain or PURL service you want, without waiting for the adoption of 888d… although 888d should allow for automatic usage due to the “wildcard” nature of the redirect based on the FEP slug.