Please add support for FEP-044f quote post authorisations

[jhenstridge]

Mastodon added support for ingesting quote posts from other servers based on FEP-044f in mastodon/mastodon#34370. With that change, it seems to already recognise the quoteUrl property bridgy-fed is generating. Unfortunately, it shows "This post is pending approval from the original author" in place of the quote.

From what I can tell, bridgy-fed would need to also publish "approval stamps". That is, the post containing the quote would need to include a quoteAuthorization property pointing at a QuoteAuthorization published by the person being quoted. This seems like it would provide room to represent whatever Bluesky's quote posting rules are on the ActivityPub side.

[snarfed]

Thanks for filing! Good idea to track this and start the conversation.

Mastodon's quote post design is pretty complicated and heavy, so it hasn't been a high priority for me to dig into. The biggest question, though, is what to translate here from Bluesky or IndieWeb. Afaik Bluesky only has the ability to "detach" the original post from the quote post, and I don't think IndieWeb has anything.

So, I'm open to this, but I don't know that there's anything to bridge yet, and it's not clear that automatically "approving" quote posts is a better default translation than leaving them unapproved.

[jfietkau]

Obligatory "I'm not a Bluesky user, but..."

If this article reflects Bluesky's current options, then you have two things that can be mapped.

The first is the choice of who can quote any given post. My understanding is that Bluesky only knows the options everyone and no one. On the ActivityPub side, this corresponds to a canQuote policy with automaticApproval set to the Public collection or the empty list, respectively. On the ActivityPub end, you may start running into posts set to only allow quotes by followers, by tagged users, or similarly specific sets. These would probably need to be translated to Bluesky as "no quoting at all" to minimize unpleasant surprises. If I understand the FEP correctly, for every ActivityPub actor that creates a quote post of a bridged Bluesky post, Bridgy Fed will need to maintain a dereferencable QuoteAuthorization object.

The second thing is the "detaching" part. When a bridged ActivityPub actor quotes a bridged Bluesky post, this quote post would be translated to a Bluesky quote post. If the Bluesky user then detaches their post from the quote, this would be translated to the ActivityPub side as a Delete of the corresponding QuoteAuthorization, which would be sent to the quoting actor to let their server know that the quote is no longer valid. Or the other way around, if a bridged Bluesky user has quoted a bridged ActivityPub user and Bridgy Fed later receives a valid Delete of the corresponding QuoteAuthorization, this should be translated to the Bluesky side as a detachment of the bridged post from the corresponding quote.

For either direction: if the original post is bridged but the quote post is not, the information about the quote will not flow back to the original author. In this case my intuition would be to allow quoting anyway, as long as the original post is set to be quotable by anyone.

N.b. I have not implemented FEP-044f anywhere or examined it super closely, so please take the above with a grain of salt. I just get the impression I'm a step or two further along the path than you are right now.

[snarfed]

Thanks for all the sleuthing, @jfietkau!

#1098 also has a bit more related background on reply controls.

[jhenstridge]

So I think there are two possible features here:

1. Posts bridged from bsky that include a quote should indicate that the quote is authorised if it hasn't been detached on the other side.
2. Allow ActivityPub users to quote bridged bsky posts.

While they are related, I'm not sure how much they would overlap code wise. I suspect (1) is probably also a lot simpler, since it would not require the "Advertising a quote policy" or "QuoteRequest request activity" parts of the spec: the bridge could just publish the QuoteAuthorization directly if the quote is allowed on the bsky side.

(2) is probably the trickier one since it would require implementing the new requests and responses, and it is less clear how a bsky user would grant consent. It probably wouldn't be too difficult to implement fixed policies like "always allow quotes" or "never allow quotes", but I'm not sure how you'd go about implementing anything more fine grained.

[renchap]

Mastodon will not have a feature where you can approve individual quotes. We will have a per-account setting for the policy on any new post you create (accept all quotes, accept only for follows, reject all quotes). And then you can detach a quote of one of your posts (by removing the authorisation stamp you provider when it was created)

I believe that if an AP user wants to quote an ATProto post, you could have all accounts accept all stamp requests (if there is no ATproto feature to prevent an account to quote you in advance). Then if the ATproto user wants to detach a quote, you can revoke the stamp.

For ATproto posts quoting another ATproto post, you can accept all stamp requests, except if the quote has been revoked (and in this case, you would delete the AP stamp and propagate it).

For the other way around (an ATproto user quoting an AP post), you can check the quote policy for the AP post. If it is not "accept all quotes", then you can detach the quote immediately on the ATproto side (except if there is a way to deny the quote at the start?)

[snarfed]

Thanks all, great ideas and info, this is very helpful and useful!

[jfietkau]

Two ecosystem notes:

1. Mastodon v4.4.0 has been released, meaning the Mastodon user base is now quickly gaining the capability to see FEP-044f quote posts.
2. dotmakeup has deployed FEP-044f for in-the-wild quote posts, so users on Mastodon version >=4.4.0 see authenticated quote posts coming from bird.makeup. I believe Mitra and Pleroma also have implementations done or in the works, but I have not yet personally come across any quote posts from them.

[silverpill]

@jfietkau Mitra doesn't support FEP-044f, only FEP-e232. AFAIK Pleroma devs also don't have plans to support FEP-044f.

[jfietkau]

@silverpill Ah, I don't remember where I read it, I suppose I or someone else got some details mixed up. My bad!