trwnh:

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.

Please don't say nothing can be done, I just gave an option. Unless you, technically speaking, consider this "blocking" too (in a way it is, just very fine-grained and very specific), but from context I assume you mean wider blocks/policies. (Which brings us back to the social problem of "look, these servers must be bad, they are on so many blocklists" for example.) It may not be the best option, it may not be a worthwhile option, but it is an option, something can be done if chosen to.

trwnh:

Trying to negotiate it as a capability is more trouble than it’s worth at this stage.

If this consideration is made, then this could indeed be a valid reason to not have it. In that case I would propose to remove the "nothing we can do about that" change in the current proposal, and also make the text less aggressive. For example

Servers not implementing this FEP will still be able to quote the post and provide no dogpiling-reducing friction. There is unfortunately nothing we can do about that.

to e.g.

Servers not implementing this FEP may still quote the post.

Maybe more explanation could be provided as to what was considered to alleviate this concern, and why it was not added, but I leave that decision to whomever writes the FEP.

Outside of this FEP; I do ask anyone who implements this proposal to make sure it is clear for those using this feature that this limitation must be taken into account, and this was a deliberate choice. But I also realise that's out of scope for this discussion.

trwnh:

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

My concern is more about the other way around, but maybe I should make the scenario more explicit;

Let's say we have A@quote-controls.example.com whose instance implements quote policies and controls as described in this proposal. And we have B@social.example.org who does understand FEP-e232 quote posts, but not the controls and policies as described here.

• A@quote-controls.example.com posts a nice drawing they made, but don't want people quoting it, so they set "acceptsQuotesFrom": "https://quote-controls.example.com/users/A".
• The post is then send out to followers, including B@social.example.org
• social.example.org receives the post, doesn't understand the acceptsQuotesFrom property, and therefor ignores it as it is required by Activity Streams 2.0; "In Activity Streams 2.0, an "extension" is any property, activity, actor or object type not defined by the Activity Vocabulary. Consuming implementations that encounter unfamiliar extensions must not stop processing or signal an error and must continue processing the items as if those properties were not present."
• 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.

trwnh:

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.

Yes! That social issue is what I am concerned about. To me, this is basically what the first paragraph of the Security considerations is also about.

trwnh:

that kind of disparity in functionality is also quite normal on the network.

I agree that it is quite normal in current fedi, but that doesn't make it OK. To use the DM example; AP makes an explicit distinction between public or not. Wildebeest leaking dm's was completely in the wrong of them and people were 100% in their right to tell Wildebeest to fix their implementation. But here we have the opposite scenario. Here the controls are not made explicit by AP. On the contrary even, AP makes it explicit that they are purely optional. As far as I still remember correctly, this is more like how current dm's were originally implemented in ostatus. (It's a very long time ago, and I was very new to the network myself, so I could be wrong on things, but from what I still remember how I understood the situation;) 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. Contrary to the Wildebeest situation, the problem here was with the sender sending dm's as basically public posts, not the receiver naively forgetting some check. And the provided fix was to not send these dm's any more to implementations who didn't understand it.

Basically what I'm saying is that we can do something about the first security consideration in a similar way;

Claire:

Servers not implementing this FEP will still be able to quote the post and provide no dogpiling-reducing friction. There is unfortunately nothing we can do about that.

I agree that A@quote-controls.example.com can't send the post to B@social.example.org and expect the controls to work. But a trade-off can be considered between wider spread, or more control. More precisely:

• Wider spread means that A@quote-controls.example.com sends out the note as currently happens, even if it means that B@social.example.org is still fully in the right to quote the post.
  • In this scenario the property "acceptsQuotesFrom": "https://quote-controls.example.com/users/A" basically means "I prefer to not be quoted, but if you don't understand this property, don't worry about it, you're still free to quote post anyhow, I'll just ignore it myself and others may as well".
  • Afaict, this is how the current proposal works.
• More control could be done by only sending to actors who indicate they understand and will enforce these controls properly.
  • In this scenario the property "acceptsQuotesFrom": "https://quote-controls.example.com/users/A" basically means "I do not want you to quote this post, and you have already told me you will respect that wish".

The second is as strong as dm's currently work, which could be a worthwhile trade-of to have. Also note that having a way for the second option, does not exclude the first option to still be available for those who prefer that.

Practical

The question for the second scenario then becomes, how to indicate someone understands and will enforce these controls. You send to actors, and when an instance fetches a post, authorized fetch uses an actor as well. So one option is to check the actor. Afaict, the current proposal doesn't have a specific property set on the actor, but maybe capability discovery can be used. E.g. (I'm using a random fep-888d-like namespace as an example, but another could be used)

{ "@context": [ "https://www.w3.org/ns/activitystreams", { "litepub": "http://litepub.social/ns#", "capabilities": "litepub:capabilities", "CompliesWithQuoteAuthorization": "https://w3id.org/fep/XXXX#CompliesWithQuoteAuthorization" } ] "type": "Person", "id": "https://quote-controls.example.com/users/A", "capabilities": { "CompliesWithQuoteAuthorization": true },}

There may be other, maybe better, ways to do this as well. But this is at least one example how something can be done about the first security concern. It could of course be considered if this is really worth having or not, but yes, at the very least communication should be clear so that no wrong expectations are set if we are to avoid such "social issues" as much as possible .

nikclayton:

There is no requirement for servers to implement any specific FEP.

It’s not just servers. Suppose I create a post in a client that doesn’t support creating a quote post, to a server that does

If your client doesn't support creating a quote post, then you can't create a quote post. Simply having a link in the content field does not make it a "quote post"; i do not see this implied in this proposal in any way, and it's even made explicit that a quote is more than (and not even required to be) just a link in the content field.

My comment is not about the quote posts themselves, it's very explicitly about the controls, expectations, and how to maybe make them more enforcable. Please do not derail.

I see a discrepancy between the blog post announcing this and the FEP as described here. The blog post reads

You will be able to choose whether your posts can be quoted at all.You will be notified when someone quotes you.You will be able to withdraw your post from the quoted context at any time.

But here it is admitted that

Servers not implementing this FEP will still be able to quote the post and provide no dogpiling-reducing friction. There is unfortunately nothing we can do about that.

There is no requirement for servers to implement any specific FEP. Therefor understanding these restrictions is purely optional. E.g. the restrictions can't say "only the author is allowed to quote this post" (as the wording in the blog post makes it sound), it can only say "if you implement this FEP and aren't the author, don't quote this post. Otherwise, feel free to quote".

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.

I see two ways around this

• Either accept that it is only a best effort and make it clear that servers not implementing this are not malicious.
• Don't send these "more restricted" posts to instances who don't understand the FEP. E.g. when someone sends a post who shouldn't be quoted, it could be restricted to only send to actors who have an indication that they understand this FEP's functionality. In this scenario there are still ways around the quoting, but at least it can then be reasonably considered malicious.