Pre-FEP: Quote posts, quote policies and quote controls

ActivityPub
21

Yes, but I’m not sure that’s relevant. 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, to create a post that links to another post instead of quoting it (assuming the user agent/server API makes the distinction) is also not in and of itself malicious activity.

You write:

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.

But in your next post you suggest:

C collapses the post under a clickthrough warning, […] You might also consider parsing the Link tag and stripping the placeholder but refusing to render the embedded preview

To me those appear to be examples of transformations you earlier believed to be out of scope.

Also, 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”.

22

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.

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.

1 Like
23

I broadly agree. However, one thing you said here struck me in particular.

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.

Is this an attempt to invent a DRM equivalent for the Fediverse?

Even considering that question feels like a derail, so that might best be discussed elsewhere.

24

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).

25

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.

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.

26

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”.

27

While I do believe a good faith attempt is being made, I still struggle with the intentions and motivations. The true thoughts of Mastodon is layered throughout all communications regarding this feature that mostly still align with the initial blogpost as to why the feature wasn’t/wouldn’t be implemented in the first place. There’s a very strong negative connotation and lack of research to support the strongly held negative views of the feature.
Other Fediverse projects has had the feature for years is there any research and evidence to support that the Fediverse is more toxic due to these platforms? Same regarding Bluesky?
There’s strong social benefits particularly by Black and Brown folk which despite maybe a few people im wiling to bet many weren’t consulted. I do recommend a few reads:

Can Mastodon be trusted to implement such a feature when it seems to be doing it reluctantly?

28

I’m very sad to read this.

A personal response here “wearing my heart on my sleeve” and in a defensive, but forward-looking, manner.

We’re in the (yes, admittedly, extended) process of being more transparent and open, in our processes and feature development. Part of that has been our voluntary annual reports; monthly engineering blog series; showing up to meet folks at Fediforum and FOSDEM etc; and the announced change of org and governance structure to a non-profit foundation in the EU. A huge part is also working with other fedi projects to discuss ideas and proposals like this one, so that they are not sudden surprises and so that we can demonstrate our thought processes and values. That’s perhaps not always what you might have seen from the project in the past.

We absolutely have been consulting with different communities - including those you’ve identified - although I’m not about to share individual identities without their express permission. My perspective - and as many of you will know, I come from a very different social media background, but with an ongoing open source and community-driven mindset - we learned a lot from those conversations. Having changed our collective position on this feature, we’ve taken the time to think about things, and we’re not “doing it reluctantly”, we’re enthusiastic about the opportunity to use what we’ve learned.

There’s really an incredible number of things to juggle as we move Mastodon forward. I’ve been working with open source (and closed source) projects for ~20 years and this is at the top end of the range of challenges I’ve had, with a small team on a widely-deployed, highly used, interoperable open platform. We cannot always do things as fast as everyone would like, and sometimes we also have to make choices that disappoint some folks: implementing every possible or proposed feature or change would cause technical debt to balloon and the function of the platform to be hidden by different bells and whistles.

Can you trust Mastodon to implement the proposed FEP? Did we need to propose an FEP, or should we have gone ahead and built something that others never had a chance to comment on or make suggestions towards? In the end, we have to make choices, or nothing moves forward. So, we’re sharing our work, and then we have to make some decisions, and build things. I can’t make you trust us, but I can tell you what we’re doing, and you can make your own choices.

Now, with that set of directional and philosophical statements made, the purpose of this thread is to discuss the technical content of the FEP proposal, rather than if/when the feature is implemented in Mastodon or other Fediverse software. There may be a better place to hold conversations about direction of individual projects in the ecosystem. We’ll respond to FEP related comments above when we’re able (not everyone is available at all times).

1 Like
29

I appreciate you taking the time to respond directly to my comment. It’s good to know you’ve reached out to some of the communities that I’ve mentioned and of course no one should be mentioned unless they’ve given explicit consent.
Be it as the reference of dunking and many of the negative terms used in the communications out word any positive benefits it does come across as reluctant.
I mentioned specific communities as it’s a big part of their social media use but in the communications I saw there was not any explicit mention of this. If I overlooked or miss something I’m happy to review and extend any apologies.
But, just to be clear my comments were never meant as an attack on the Mastodon team nor anyone. The efforts for collaboration and go about this feature in a thoughtful manner are very much appreciated

2 Likes
30

First thank you for your work on this. :+1:

I think one should specify the possible recipient set of quote posts. Here is my thinking:

  • The post by Bob needs to be visible to Alice in order for her to sensibly judge if Bob should be allowed to quote it.
  • Direct Messages containing quote posts make little sense, as they would need to include Alice.
  • We are worried about abuse / moderation. It would thus be sensible to require Quote Posts to public, i.e. require as:Public to be in either to or cc. See this post by @jenniferplusplus on why followers only quote posts would be an abuse vector.
  • Specifying that Bob WILL include their followers collection makes it clear that a quote post constitutes a change of audience. It goes from Alice followers → Bob’s followers (similar to an Announce).
31

Quote posts don’t need to be public, but they do need to obtain a stamp from the authority. Alice may refuse to grant a stamp for any reason, arbitrarily and on a case-by-case basis. Most likely, Alice will want to see the post before stamping it; i.e. Alice does not want to blindly stamp anything. If Bob wants that stamp, then Bob would do well to ensure that Alice can see Bob’s post. Alice then has more information and can decide whether or not to grant Bob a stamp.

2 Likes
32

This part is not normative. The presence of the URL in the post text has no special meaning. This proposal does not define whether it should be added by the server or not. This does not define where the quoted post should be inserted. The presence of this text in the example mirrors the common use case where the user writes this out, the client notices the link, and attaches a quote to the post.

The idea was that a missing acceptsQuotesFrom would correspond to an empty acceptQuotesFrom, meaning only the author and mentioned users would be assumed to be able to quote it. This should probably be made explicit.

It is an array. The sentence making that explicit has apparently been lost along the way, I will fix this.

A previously-authorized quote remains valid unless the stamp is deleted.

This is not limited by the proposal. But the plan in Mastodon is to only show the first one.

This is up to the author (or the piece of software they use) of post B. The post does not need to be edited in any way, though it would make sense to at least remove the link to the approval stamp since we know it is not valid anymore.

This is not defined by this proposal.

This is indeed not what this proposal allows. Quoting only fragments of a post has different issues/considerations (e.g. omitting text to specifically misrepresent a post) and is not supported by this proposal.

Your other remarks are purely UX decisions that are out of scope for this proposal.

33

We initially considered text or markup matching to replace a portion of the content with the embedded quote, but we have decided against it, as it would make both the implementation and the interface significantly more complex for very little benefit.

This proposal does not define where the quote should be displayed, and does not define any content/text replacement.

As @silverpill mentioned, FEP-e232 is not only about quote posts. Furthermore, adding approvedBy to the Link object allows us to easily match approval stamps with the intended quote, instead of having to mix-and-match quotes and approvals in case there are multiple ones.

As for the specific rel value of https://misskey-hub.net/ns#_misskey_quote, we are not against changing it, but we picked this one for compatibility with existing implementations.

34

Quote posts are not treated as a reply to the post they are quoting. Those are completely separate mechanisms. A quote post can reply to something while quoting something else.

I think this and a few of your other questions boil down to a misunderstanding: the policy is advisory, as in, it tells would-be quote-posters whether they can expect their quote to be accepted. They are not used to verify whether a quote is approved or not. There are two reasons for that:

  • policies may involve private collections a third-party cannot check
  • this allows changing a policy without invalidating existing quotes (individual quotes can be revoked by deleting the individual approval stamps)

Verifying whether a quote is valid is done by checking the stamp, not the policy.

This is out of scope for this specification, which is about ActivityPub. An ActivityPub client talks ActivityPub, and your comment does not make much sense in this context. I believe you are worried about the Mastodon API. In this case, the Mastodon API for this is not defined yet, but the idea is not that the server automatically convert links to posts, but rather that the client would explicitly attach a quoted post (possibly by detecting links at compose-time and asking the server whether the links are suitable for quotes). But again, this is out of scope for this document.

35

RE: ... is primarily used as a fallback for platforms that don’t support quote posts. I think this text should always be added.

36

I understand your concern, we indeed can’t force other servers to comply with the policy, and not complying with the policy is not necessarily malicious either.

I don’t think we should do some kind of compatibility negotiation given that it would make the whole thing more confusing, as it would be difficult to reason about why a post has reached a server and not another. Especially when you factor in that we want to require explicit consent to quote, and that current versions of Mastodon have no way of advertising such consent.

I guess we could make the representation of quote posts purposefully incompatible with what currently exists, so that the spec defining them would also mandate respecting policies and verification stamps… but this would not prevent the other existing implementations from existing.

37

I’ve been meaning to give this proposal some proper consideration, and I still intend to do that. But, I have a few minutes now and I want to share some initial thoughts. Overall, I really like what’s happening here. I love that there’s a proactive advisory policy. I love that it’s a property of the note/post. I love the authorizing stamp/token. I love that it’s revocable. I wish it could be self verifying, but that’s by no means a deal breaker for quotes. I’m ambivalent about the Quote activity.

The biggest thing I would want to change is to make these things less tightly coupled to quoted posts. Particularly the authorization token. I wish that it was a generic claims token, rather than a special purpose token for quote posts. Having an inter-actor authorization mechanism would be incredibly beneficial for the whole fediverse. It could enable moving actors and content when the original host is offline. It could enable the most critical parts of reply-control.

I would really like to tackle authorization stamps and advisory authorization policies as their own first class concerns. It’s probably easier to do that before taking quotes to a proper FEP, but I also wouldn’t want to make it into a blocker for quotes.

2 Likes
38

I would agree, but I focused on quote authorization specifically because:

  • it solves the possible ambiguity regarding purpose of approval (e.g. if someone is both replying and quoting you, are you approving the quote, the reply, or both?)
  • it doesn’t have the same issues as with replies with regards to deciding who gets to have the authority over replies or reply threads
39

I am a bit unsure about how to go with this, and I’m not sure it should be specified in the same document (though admittedly the current draft already defines multiple concerns and could be split in multiple documents, e.g. quote post representation, privacy policy definition, and approval mechanism for quote posts).

Honestly, I would have liked to avoid specifying that, but it does make sense. This does bring a few UX challenges though:

  • automatically adding text to the user’s post without them explicitly putting it there seems a little iffy to me
  • when quote posts are supported, the extra text is redundant… so we probably want to automatically remove it

The simplest actual solution I have seen in the wild for the latter is what (at least some versions of) akkoma does:

<span class="quote-inline"><br/><br/>RE: <a href="quoteUrl">quoteUrl</a></span>

We could say that a client could hide the quote-inline class of posts that are known to have attached quotes (verified or otherwise).

1 Like
40

I was thinking a little more about this, and while having a purposefully incompatible representation of quote posts would be a good way to draw attention to a spec that mandates support for quote policies and controls, this would not fundamentally solve the issue of that just being a spec and other implementations possibly handling quote posts in their own way without being explicitly hostile.

The only way around that would be to completely break federation for pretty much every post, which is definitely not reasonable.

(For completeness, one idea we thought about was to use a different rel value such as https://joinmastodon.org/ns#verifiedQuote, which would draw attention to the spec and to the notion of verification, but would not fundamentally fix much; also compatibility could still be preserved by using multiple rel values)