Proving “quote replies” and “Announce with content”
The prior post explores various approaches to defining what is a “quote”, but one thing that was left out of the original post was any sort of consideration of how to “prove” any or all such definitions of a “quote”. More precisely, it is generally desirable to have some mechanism to seek and signal the consent of the quoted person for the quoted segment. In the case of quotes, there is no special collection for tracking quotes, so an approach like https://w3id.org/fep/0391 is not applicable here unless a) you limit yourself to quote replies or Announce-with-content, which inherit the same “proof” considerations as any other item in replies or shares, or b) you define exactly such a quotes special collection, and probably a corresponding semantic property quoteOf which works similarly to inReplyTo… assuming you can precisely define what it means to “quote” something, semantically speaking. But in any case, we have other approaches than simply trying to establish membership in a special collection.
Proving “quote tags”
A “quote tag” was defined previously as a rich tag entity that can be embedded in the rendered content by processing microsyntax in ways similar to other tag entities. Prior work on FEP-e232 uses a Link in tag with the AS2/AP mediaType, but we can extend the semantics as previously described, either through the use of a rel link relation like the _misskey_quote one, or by defining something like a Quote type which may be a subtype of Link, intended to represent what is more or less a blockquote with probably a source or cite. This is mostly besides the point, though; the interesting question that I’d like to explore here is how to obtain and signal consent for such “quote tags”.
Using the preview property of Link?
A possible extension to FEP-e232 would be to use the preview property on a Link in tag, signaling that the link is intended to have a rich preview. This is an alternative to fetching any/all links yourself and parsing for OpenGraph or meta tags in the HTML head (in the case of a Link where the mediaType is text/html or assumed to be so). A common problem this would address is the “thundering herd” issue where linking to something on the fediverse often triggers a lot of GET requests to the linked resource, within close temporal proximity of each other, to the point that it can cause unintentional service degradation for the linked resource’s provider if their service is not optimized to handle a large volume of requests within a short period of time (for example, by utilizing a static cache). However, it would create a new trust issue for anyone who wants to consume such a Link.preview. Exploring a credibility or reputation mechanism to discourage activity/object producers from lying about link previews is out of scope of this post, but it could be done.
Obtaining a previewProof
An extension property previewProof could exist directly on the Link/Quote tag. What this points to is left open, but it should in some way be associated with the preview.
Signing the preview directly or using a Verifiable Presentation
Or, the proof could instead be part of the preview itself. One way to do this is with Verifiable Presentations.
https://www.w3.org/TR/vc-data-model-2.0/#verifiable-presentations
This data model comes with its own mechanisms for establishing proof. Some entity with a key defined as an assertionMethod could assert that it approves of the preview. (The VCDI stuff is also the foundation https://w3id.org/fep/8b32 styled “data integrity proofs”, but they can be used in other ways as well.)
The generic way you’d obtain and use such a proof could be described as follows:
- You send some authority some material to sign, as well as potentially supporting information on how you’re going to use the resulting signed material.
- The authority sends back the signed material. This step could be subject to either an automatic action or a manual human-approved one.
- You attach the signed material to your activity, where appropriate. You can now send your activity to your desired arbitrary audience, and any recipient can verify that the proof is valid for the signed material.
There is still a potential consideration for the lifetime of the proof, as well as revoking an earlier proof. For this, I point to the concept of a “credential status” from the VC Data Model:
https://www.w3.org/TR/vc-data-model-2.0/#status
Basically, you can link to an external “status” indicator, or some other external “revocation list”, by which you can detect when the signed material is no longer to be trusted.
Alternatively, you can establish a system where the Verifiable Presentation is fetched directly from the issuer of the associated credential.
The exact mechanics of these suggestions is left out of scope for now.