Pleroma patch has been accepted: TagValidator: Drop unrecognized Tag types (!3823) · Merge requests · Pleroma / pleroma · GitLab
We’re getting closer to finalization. If there are no objections, I’m going to list known implementations ((streams), FoundKey and Mitra) in the corresponding section of the proposal.
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.
Fragment selectors that can be included in URIs:
| Name | Fragment Specification | Description |
|---|---|---|
| HTML | RFC 3236: The 'application/xhtml+xml' Media Type | [rfc3236] Example: namedSection |
| RFC 3778: The application/pdf Media Type | [rfc3778] Example: page=10&viewrect=50,50,640,480 |
|
| Plain Text | http://tools.ietf.org/rfc/rfc5147 | [rfc5147] Example: char=0,10 |
| XML | http://tools.ietf.org/rfc/rfc3023 | [rfc3023] Example: xpointer(/a/b/c) |
| RDF/XML | RFC 3870: application/rdf+xml Media Type Registration | [rfc3870] Example: namedResource |
| CSV | http://tools.ietf.org/rfc/rfc7111 | [rfc7111] Example: row=5-7 |
| Media | Media Fragments URI 1.0 (basic) | [media-frags] Example: xywh=50,50,640,480 |
| SVG | Scalable Vector Graphics (SVG) 2 | [SVG11] Example: svgView(viewBox(50,50,640,480)) |
| EPUB3 | EPUB Canonical Fragment Identifiers 1.1 | [cfi] Example: epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/3:10) |
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.
Pleroma is going to support quoting: Quoting (!3921) · Merge requests · Pleroma / pleroma · GitLab
FEP-e232 tags are accepted (along with quoteUrl and other similar properties). There’s also an MRF that adds FEP-e232 tags to outgoing posts.
it sounds like i should probably tackle that “quote” FEP soon or at least make a thread to share my analysis on it. there’s definitely a few approaches, and they all have some validity.
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\""
, etc.
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.
ActivityPub, Section 7, “Server-to-Server Interactions”:
POSTrequests (eg. to the inbox) MUST be made with a Content-Type ofapplication/ld+json; profile="https://www.w3.org/ns/activitystreams"andGETrequests (see also 3.2 Retrieving objects) with an Accept header ofapplication/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’.
See Activity Vocabulary for all the nitty gritty details.
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.
If a known bad actor (or actually anybody) hits my site with a quarter million requests in 20 minutes, I don’t care what the spec says. I’m not responding.
So sue me.
Link: Disambiguating various interpretations of a "quote" feature [pre-FEP]
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_quotetype: 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.
Yes, I think quotes collection makes sense (but it should be optional).
I’d like to add more examples to this FEP to clarify how object links can be used.
Opened #173 - WIP: FEP-e232: Add more examples - fep - Codeberg.org which adds an example of a link to a ticket on a federated code forge.
Pleroma v2.6.0 includes a fix for tag validator and a MRF module that adds FEP-e232 links to posts with quotes.
I’m adding it to the list of implementations: #203 - FEP-e232: Add Pleroma to implementations - fep - Codeberg.org
It is time to finalize this proposal.
In accordance with the FEP process, I hereby request final comments.
FEP-e232: Object Links is now FINAL.
Threads implemented FEP-e232.
Example: https://www.threads.net/ap/users/christophersu/post/17989631141598693/ (requires signed request).
They are using https://misskey-hub.net/ns#_misskey_quote as rel value.