+++
title = "quote semantics"
summary = "it could be just a link with a rich preview. or it could be more than that."
date = 2024-10-15T12:39:00-05:00
source = "https://discord.com/channels/1100160301254590525/1185342677974270092/1295803370988113941"
+++

> But all of this is why our work right now is on studying what other software do [regarding quotes], so we have a good view of whats in the wild, what works, and what we should do

is the consideration only for other software or are you willing to consider general fundamental reality

by which i mean: you can’t stop anyone referring/linking to you as long as they have an identifier/link. it is fundamentally a dead end to try to prevent that especially in a decentralized open world, so you need to reframe the question outside of your ux assumptions. what you need is something to prove. for replies, this means checking the replies collection instead of re/assembling every inReplyTo yourself. at a ux level the question of “what are the replies to this post” should translate to “what is in the replies collection” at a protocol level. which is not the same as “which posts do i know exist that have this inReplyTo”. do you see the difference in framing? deferring to the canonical replies collection respects the authority of the owner to manage it, while the latter option is to ignore their authority entirely. it’s a similar thing with a Follow activity not being enough to tell you that someone is a follower — you don’t know the contents of the collection.

for “quotes”, then you need to be very precise about what a “quote” is and how do you “prove” a quote by that definition. otherwise none of the explorations you’re doing make any sense.

for what it’s worth, i think you could define a “quoteOf” property and a corresponding “quotes” collection but you shouldn’t codify a ux assumption as a generic semantic relationship. because what does it mean for something to be a “quoteOf” something? what are you trying to convey on a semantic level, outside of your app-specific ux concerns?

something that might also be workable is to build on e232 and a) define a Quote type as a subtype of Link, b) use the preview property of Link to point to the status being quoted, c) require some proof to be attached to that Link/Quote or the preview itself. if it went directly on the tag it would be a “previewProof” property. otherwise maybe use Verifiable Presentations.

[...]

this is why "controls" is the wrong way to look at it, and "verification"/"proof"/"stamp"/etc is the correct way to look at it. another way to frame it is, given only the activity or "post" object, do you have enough information to know that the preview is genuine?

like, this is closer to the generic link preview case or possibly "how do i markup a blockquote" levels of problem, not trying to prevent the mere existence of a link

> you always do, because quotes work by referencing the original post object, and you consider it trustworthy because you've fetched it yourself from its origin server

referencing the original post is not enough information, nor is it enough for a "quote". a reference is just a reference.

if you think a "quote" is just a link then i can see why you think this is all pointless

> yes, it's just a link that's rendered differently

i'm talking semantics here. like how inReplyTo carries the semantics of "i am responding to this". a "quote" can be defined as just a link with a rich preview, but i think there's more to it

in other words what does it mean to "quote" something

at the simplest level you can treat it as a rich preview of a generic link, but there's more complexity you can add. what if the quote is citing or reproducing only part of the content? this is a common thing on forums for example. what if you quote multiple things, or quote the same thing multiple times? what if you edit the content of the quote? what if you substantially edit the content of the quote? what if you don't have the original resource? what if you want to handle quoting private resources within certain contexts?

i am personally not interested in being limited to twitter-style quote tweets. that (anti-)feature is nothing more than taking the link at the end of a post and giving it a rich preview. it could be handled by opengraph tags for all i care. i am far more interested in modeling precise semantics. this is why i think it could be done as `tag[].Link.preview` where there is either an accompanying previewProof or otherwise relying on Verifiable Presentations or something similar, where whatever the preview is, it has some associated signature with it.

the general idea or flow is something like
- you send the authority some material to sign
- the authority sends back the signed material
- you attach the signed material to your activity

that material could be a preview object or it could be your full activity or whatever

the "point" of all this is to establish consent