Doesn't this mean Mastodon users et al will no longer get boost notifications when their posts are reshared into a topic? If you’re never actually resharing the post itself, this prevents cleanly tracking all shares.

Sorry, I should be clear: fine-grained policies are still policies. It's the responsibility of various softwares to give people the tools to control their communications as they wish, and if softwares only allow for broad policies like "completely sever communication with this actor", then this is a problem that needs to be fixed more generally.

WRT the actual text being made "less aggressive", sure, that seems like a good idea. There's a very slight distinction I'd make between "quote this post" versus "create posts that get interpreted as quote posts", but I recognize that this might be too fine a distinction for most people to care about. To me, I make the distinction because I want to distinguish between the post and the Quote activity. So it might be more something like:

Servers not implementing this FEP can still make posts that match our representation of a "quote post". We cannot control the behavior of any other software, but we can apply local policies such as requiring stamps before rendering such representations as a "quote post", or otherwise making UI distinctions between "approved quotes" and "unapproved quotes".

It’s not really DRM because there’s no restriction mechanism and it isn’t about any “right” so much as it is about consent. Instead of technical protections or restrictions it’s just another signal that can be optional or required or ignored as anyone sees fit. You could do something similar with Mention nodes since they are a subclass of Link; perhaps you grant capability to signal “approved mentions” and revoke it when you block someone. Of course, for this kind of thing to be effective then your audience needs to fundamentally agree with you on policy. Say the policy is to unlink mentions and not copy a recipient if you reply to a post. This would be an implementation decision based on the same mechanism of “approved links”.

To be clear, you have three things going on here:

• The Link tag which signals a “quote post” to anyone sharing that definition. Other representations and definitions are possible.
• The Quote activity which allows you to notify someone that you quoted them. You could stop there and it would still be useful as a notification type.
• The approvedBy property and stamp mechanism which allows you to provide proof of acknowledgement. This concept of “approved links” is a progressive enhancement to a regular link.

These three things can be used independently of each other. The concerns have been separated to allow for this.

The outstanding shortcoming of using approvedBy on a Link is that most things in AS2 aren’t actually Links, they’re direct relations via the predicate and the object resource. So this wouldn’t work straightforwardly with replies for example, since inReplyTo ideally points to an object. At the very least, the ecosystem would have to support Link values for inReplyTo (or otherwise define a property like inReplyToAuthorization. A similar problem would apply if the chosen representation of a “quote post” relied on a property like the myriad properties in use by various projects (quoteUrl, quoteUri, _misskey_quote).

There’s also a tangential concern about whether this whole “put a Link in tag” thing makes sense, or if tag is the appropriate property for this. But those are separate issues being tracked elsewhere (like the w3c/activitystreams and w3c/activitypub repos on github). It’s technically an indirection mechanism when perhaps a more direct relation might be more correct or useful (for example instead of tagging a Mention of a Person, you could just tag the Person).

nikclayton:

The comment I was responding to (and support) says:

The biggest problem I see is that current wording make it sound like any server not understanding the FEP is automatically malicious. But if it’s optional, it’s not malicious to not have it.

My point is that a user directing their user agent, connected to a server that supports this FEP

trwnh:

The confusion likely stems from “server” being ambiguously used in the same sense as “Mastodon/etc instance” and not “ActivityPub server”.

A user might direct their user agent toward a "server" which is itself an "ActivityPub client". The considerations of the user agent are not the same as the considerations of a "client"; there are in fact multiple layers of "client" relations. Mastodon et al are in effect HTTP user agents that transform and re-expose information via the Mastodon API.

My citing potential policies of individual actors or their host services is meant to illustrate that those policies are applied without affecting the canonical representation of anything. The transformations are "out of scope" because it's not in anyone's control what others end up doing with a resource. As far as a publisher is concerned, someone generated an AS2 document and they're making it available. As far as a consumer is concerned, that AS2 document may or may not contain something that could be interpreted as a "quote post", and there may or may not be a stamp associated with it.

nikclayton:

I find it hard to agree that concerns that – may be – Mastodon specific are out of scope for this discussion, when the preamble for the pre-FEP starts

Quote Posts are an often-requested feature for Mastodon

and goes on to say

This is a work-in-progress document describing Mastodon’s proposed way of representing quote posts

And as I said upthread, “some of my questions below are driven by user experience considerations. It’s my experience that failing to consider the desired end user experience early enough in the process can result in specs that are not suitable”.

It may be that we disagree, but my position is that the "end user" and the "end user experience" is not in any way required to conform to Mastodon's expectations. Overfitting to "user experience" makes the protocol far more limited in a way that isn't necessarily good. The suitability of a spec like this is not in whether it works for Mastodon, but in whether it works broadly and generally to things that may or may not be anything like Mastodon. The fediverse consists of more than just Mastodon, and more than just microblogging. At the level we're working with here, there is no such thing as a "post" or a "status", there is only an Object with a Link tag, and that Link may or may not have proof of consent attached. There's a million things you can do with that, and I'm not sure how useful it is to enumerate those things and consider them individually.

ilja:

• B@social.example.org really likes the drawing and wants to bring attention to it, quoting the post "Look what awesome drawing, this is so cool! :blobfoxaww: "
• A@quote-controls.example.org, expecting that other are not allowed to quote post, somehow learns that B@social.example.org did quote the post.
• A@quote-controls.example.org is now very angry at B@social.example.org even though B@social.example.org did nothing wrong.

It would be up to A's software at quote-controls.example.org to explain to A that B's post is "unverified". quote-controls.example.org might hide or reject or modify B's post, which means A is not seeing the same thing as what B is seeing, or what C or D might see as outside observers. If C checks for the stamp and finds it missing, it can apply a policy that isn't necessarily the same as A's policy; perhaps A strips the quote from the post, C collapses the post under a clickthrough warning, and D drops the post entirely. Everything looks fine to B, but what matters here is how everyone else behaves. In my opinion, the most consistent policy is what A is doing: to ignore the Link tag that makes it a "quote", but leave the fallback in content. You might also consider parsing the Link tag and stripping the placeholder but refusing to render the embedded preview, but it's probably better to show a simple link instead of showing a useless box. This stuff is all up to the various implementations, though -- all we can do at a protocol level is allow people to verify stamps as an optional step (and then it's a matter of policy on whether you require stamps or not). The intent is for more servers over time to understand, respect, and validate stamps. If a server doesn't do this, then there isn't anything that can be done other than to apply policies like blocking that server. This is up to users and admins to decide on a case-by-case basis.

ilja:

this is more like how current dm’s were originally implemented in ostatus [...] They were first implemented in public posts in a similar optional way by adding some property which would be ignored by instances not understanding it, so dm’s started to “leak” through implementations who didn’t understand this optional extension

Yeah, that's the gist of it. But it still comes down to policy in the end:

ilja:

you’re still free to quote post anyhow, I’ll just ignore it myself and others may as well”.

which should be the default expectation.

Think of it like this: anyone can link to anything. It’s not a matter of capability. But what you want to prove is that consent was obtained. That’s what the stamp does. I suggested the name “stamp” precisely to draw the analogy to how actual stamps work.

Trying to negotiate it as a capability is more trouble than it’s worth at this stage. But I do think some kind of protocol negotiation would be useful to have as a more general framework. This kind of effort is something I proposed as a SocialCG task force back in November, but it never got resolved because the focus right now is on charter stuff.

If you mean "client" in the sense of "Mastodon API client", then this is the wrong place to have that discussion. The relevant parties here are HTTP user-agents and AS2 publishers/consumers. In the case of a generic server and generic client, the server is basically an agnostic storage and delivery component for arbitrary JSON-LD payloads (perhaps with a few constraints imposed by AS2-Core). The client in this case is occupying the same niche as a Mastodon instance: it generates AS2 activities which the server uses to publish a document/resource and deliver notifications. The document representing the "quote post" is entirely in the purview of whichever entity generates that document (the Mastodon instance). Downstream of the AS2 documents generated by Mastodon, this means that you will have to set those guidelines and expectations for the Mastodon API. For example, the Mastodon API will take a string starting with @ or # or https:// and attempt to interpret and auto-link those. Similarly, Twitter would auto-convert any post ending with a link to a tweet into a "quote tweet" (or auto-convert any post starting with d username into a direct message, for that matter). But these kinds of transformations are out-of-scope here. As far as the protocol level is concerned, content is an opaque string that may be parsed as HTML by default. What that HTML contains is dependent on who generated the AS2 document. So it is nonsensical to say "a server may implement the FEP, but a client of that server may not support creating quote posts." when the client is the one generating the AS2 document. There is nothing for the server to support about arbitrary and opaque data. The confusion likely stems from "server" being ambiguously used in the same sense as "Mastodon/etc instance" and not "ActivityPub server". If a Mastodon API client doesn't support quote posts, then it can't make quote posts. That's it. Any and all other concerns should be discussed with the Mastodon project.

ilja:

accept that it is only a best effort and make it clear that servers not implementing this are not malicious.

I think there are other factors to consider here:

First, the representation of a "quote post" is separate from the Quote activity, and separate from the QuoteAuthorization stamp. This means that the representation can actually be changed in the future without affecting the Quote/Accept(Quote) flow at all. But for now, given two softwares both understand the same representation, where software A supports the Accept flow and/or stamps, and software B does not, then a "quote post" coming from B is subject to the policies of A on how it wants to handle the authorization/validation aspect:

• A can show B's "quote post" as-is
• A can hide B's "quote post" in part, or otherwise refuse to treat it as a "quote post"
• A can fully hide or reject B's "quote post"
• (etc)

Essentially, the lack of support or awareness from B is not necessarily malicious and in some ways is not necessarily a significant problem either. What matters is what some third party observer C will do.

Which leads into the second point: the way the stamps are defined to work, they are agnostic to how they are used. The purpose of a stamp is to allow for verification or acknowledgement, in the same way that an official or authority might stamp a piece of paper, a letter, or an envelope in order to signal that it has been approved. But it's up to you whether you want to recognize the authority of that stamp. There are cases where you might not even check the stamp -- say for example that your policy allows mentioned users to quote without needing a stamp. Again, it comes down to policy.

The question then is about whether any given servers share the same policy. If they do, great! If not, then there might be social issues that arise because of that. And the difference between malice and ignorance is irrelevant to that situation. Remember when Wildebeest would leak "DMs" because they only understood "Public"? That's a more drastic example, but the general principle here is that even if some remote server is overly naive or unaware, then you still have to deal with their behavior. So yes, it's "best effort", but so is everything else on the network. Perhaps the language of the blog post can point this out more explicitly, that "can be quoted" is a function of whether the observer validates or not.

It could also be somewhat avoided in the case where two given servers do not share the same representation of "quote posts". But again, that kind of disparity in functionality is also quite normal on the network.

regarding object and target having a domain of Activity, my suggestion was/is to define new properties specific to the stamp object and its QuoteAuthorization type. there's no real reason to stick to AS2 Vocab here. if you were to reuse AS2 Vocab then the only properties applicable are context (signaling purpose) and inReplyTo (signaling response). this technically works in a semantic sense, but only in a broad general sense. "the authorization stamp exists in context of the quoted post, and it is a response to the quote post."

the more specific way to describe it is to instead define something like authorizationOf and authorizationScope or whatever names you wanted to bikeshed.