Repository navigation
Please add support for FEP-044f quote post authorisations #1956
Description
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.
Activity
snarfed commentedon Jun 4, 2025
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 commentedon Jun 4, 2025
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
canQuotepolicy withautomaticApprovalset to thePubliccollection 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 dereferencableQuoteAuthorizationobject.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
Deleteof the correspondingQuoteAuthorization, 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 validDeleteof the correspondingQuoteAuthorization, 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 commentedon Jun 4, 2025
Thanks for all the sleuthing, @jfietkau!
#1098 also has a bit more related background on reply controls.
jhenstridge commentedon Jun 5, 2025
So I think there are two possible features here:
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 commentedon Jun 6, 2025
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 commentedon Jun 7, 2025
Thanks all, great ideas and info, this is very helpful and useful!
as2.from_as1: add class="quote-inline" to RE: ... quote URL prefixes
update tests for AP class="quote-inline"
jfietkau commentedon Jul 9, 2025
Two ecosystem notes:
silverpill commentedon Jul 10, 2025
@jfietkau Mitra doesn't support FEP-044f, only FEP-e232. AFAIK Pleroma devs also don't have plans to support FEP-044f.
jfietkau commentedon Jul 10, 2025
@silverpill Ah, I don't remember where I read it, I suppose I or someone else got some details mixed up. My bad!
jfietkau commentedon Sep 15, 2025
I was talking to someone about this issue today and figured I'd pop by with a collection of things I've learned since July.
Since FEP-044f considers self-quotes exempt from the approval process (they are automatically considered approved), bridged self-quotes from Bluesky (example) already show up just fine on Mastodon >=4.4. (Side note: a similar exemption from the approval process for tagged users was removed from FEP-044f in late July.)
Bluesky posts where a bridged account quotes a non-bridged one (example) continue to (correctly) show the fallback link.
Constellations that would require FEP-044f implementation work to be visible as quote posts on Mastodon include a bridged Bluesky account quoting a different bridged Bluesky account, or a bridged Bluesky account quoting a bridged ActivityPub account. Since I'm not really a Bluesky user, I don't know how exactly it would be presented the other way around. If you're currently bridging other AP quote posts, I guess Mastodon quote posts where both parts are bridged would already work. Quote post authoring will be enabled on mastodon.social and mastodon.online this week, as it happens, so Bridgy Fed will start encountering a lot more AP quote posts very soon.
It's also worth noting that from what I have picked up via various direct channels, i.e. this has not been officially announced, Mastodon will likely reuse this same Request-Approval pattern for future interaction controls. Someone (sue me if I'm misremembering but I think it was Eugen) posted that Mastodon wants to tackle reply controls after quote posts are out and finalized, and those will almost certainly reuse this schema. Even more tentatively, Mastodon's planned starter packs will most likely also use something similar to manage permissions, so any Mastodon user will be able to set a preference on whether they can be added to starter packs, see a list of starter packs they're currently in, and remove themselves from individual starter packs. I don't know if starter pack membership is something Bridgy Fed will consider in-scope for bridging, but reply controls most likely are (#1098 was already linked), and the “permission stamp” implementation should be reusable there to a large extent.
Meanwhile, GoToSocial (where this schema was AFAIK first implemented) is leaning into it even harder for its general interaction controls. They note the coordination with Mastodon on quote posts. My understanding is that GTS's quote posts are not yet FEP-044f compatible, but should become so with version 0.20.
Other links:
renchap commentedon Sep 15, 2025
This is on our todolist, and we may do it in a similar way (as GTS does, we worked together to ensure their controls and FEP-044f can work together), but we do not have any hard plans right now
This is correct and we are actively working on Starter Packs, and intend to publish an FEP that will include them using stamps to confirm the user allowed to be included in the starter pack. More news on this in the coming weeks.
mackuba commentedon Sep 18, 2025
Bluesky posts are currently bridging into Mastodon as "not quotable":
56 remaining items
ids.translate_object_id: translate bridged AP ids to their native ids
jfietkau commentedon Oct 5, 2026
I'm not certain I follow how that makes sense, but if you're correct and it's a fleeting problem, my understanding won't matter much, and if it's not, I suppose we'll be seeing the problem again soon enough.
activitypub: send QuoteRequests and handle Accepts for quotes of AP p…
Protocol.targets: add to_proto kwarg
activitypub: noop: rename handle_quote_accept => maybe_handle_quote_a…
snarfed commentedon Oct 5, 2026
Done! We're now sending
QuoteRequests, handling incomingAccepts, and including theirquoteAuthorizations in our outbound posts.I think that's everything. New quote posts of new original posts should now all work; tentatively closing. Please let me know if you see anything that looks off!
jmcken1 commentedon Oct 5, 2026
I dunno whether it’s intentional, but a lot of bridged Bsky→Masto reposted quotes are showing up with “Post pending” placeholders like this (original):
What does this mean exactly? Does the owner of the quoted account see a request for permission? Until/unless that permission is granted, would it perhaps be better to replace these non-embeds with a link, so that users who see the quote can at least click to view the quoted post?
jfietkau commentedon Oct 5, 2026
This is likely the problem I pointed out a few comments back: when a bridged Bluesky account quotes a non-bridged Bluesky account, the quote post should be shown as a link since there's no ActivityPub post to quote. However, Bridgy Fed currently sends these posts out in a way that causes Mastodon to attempt to display the quote, which inevitably fails. Mastodon intentionally does not render the link, since the constellation is indistinguishable from a non-consensual quote from the viewpoint of the server displaying the post.
I suspect the inclusion of the FEP044f LSON-LD context in combination with the use of the
quoteproperty to be the likely reason for this change in behavior. If I'm right, this could be fixed by omitting the new quoting context on posts which quote non-bridged accounts – or by removing thequoteproperty from such posts, but presumably that one serves a purpose on Misskey or something, I'm not actually sure. It's been there for ages, so it isn't a problem on its own.No, neither of the two Bluesky users currently has any way to influence this.
ActivityPub._convert: omit quote fields for quotes of posts not avail…
snarfed commentedon Oct 6, 2026
@jfietkau yes! At that time, the issue was a bit different; the quoted posts didn't have metadata inside Bridgy Fed to be quotable. But you're right about the latest deploy, it did regress quotes of non-bridged posts this way. I'm deploying a fix right now. Thank you for your detailed sleuthing here!
mogul commentedon Oct 7, 2026
Thanks a lot, this has been a huge improvement so far!
FWIW my stress test is @gottalaff.bsky.social@bsky.brid.gy
snarfed commentedon Oct 7, 2026
Glad to hear it!