Sounds like Signaling side effects asynchronously by generalizing Accept/Reject maybe?
In any case: only post-facto rejection of replies doesn’t work for the use-cases described. specific comments below:
this vastly increases traffic that would be considered not only useless, but counterproductive. you are basically advertising the existence of a reply.
similarly: just don’t advertise any unwanted Likes or Announces.
this could work in theory but it would be a bad idea. if you’re going to check a collection at the origin, then just check the actual replies/likes/shares
aside 1: what is a “quote” and how does it relate here
if “quotes” were just replies that embedded the replied-to object, then “reply controls” would also be “quote controls”. i would argue there’s actually near-zero difference between a quote and a reply; a quote is just a reply with an embed. one only needs to look at how a “reply” is rendered in the IndieWeb space to see the similarity to “quotes”. See https://aaronparecki.com/replies for an example of this.
i don’t think it makes any sort of sense to try and prevent people from typing or pasting a hyperlink into the content; on that front, what we might seek to adopt countermeasures for would be to disable embeds or previews via OEmbed.
offtopic: consider a toot:quoteReply boolean that, if true, indicates that the inReplyTo object should be embedded above while rendering the current object. mastodon could then change/relax its policy of not showing replies in feeds, and insert such posts into the feeds of followers (or make it an option? idk, this is an implementation detail, and other implementations already show all replies anyway)
aside 2: about contexts and conversations
if you had a first-class concept of a “conversation” that isn’t just a reply-chain, then such a “quote” may or may not be part of the same discussion (copy the context), or it may be part of a new discussion (set your own context), or it may be not a part of any discussion (in the default global context of null). seeing as how it makes sense to have a concept of a “moderated conversation” or “authoritative context”, we derive the following consequential cases:
- support reply stamps/proofs/approvals, proving that a reply was added to
inReplyTo.replies - support context stamps/proofs/approvals, proving that an object was added to
context - support both
aside 3: Accept or Add?
so far the discussion and proposal has mostly assumed an Accept activity would serve the purpose… and it very well might. but wouldn’t an Add do the same as well? in fact, an Add could be distributed to the followers of the person being replied to, as well as to the person replying; the person replying can then reference that Add activity as proof, or even inbox forward it to their followers.
for revocation, i don’t think this is actually any different either; you just stop serving the “proof” activity, regardless of its type. if anything, you can explicitly send a Remove to your followers, and possibly to the author of the removed reply. if they are a good actor, they might forward it to their followers. if they are a bad actor, they might harass you about it and get blocked/reported.
it would also probably address this concern:
if you send an Add to replies, then that’s unambiguous.