MastoAPI quote incompatibility

Oneric commented

2025-11-14 23:32:35 +00:00

Owner

We long had quote and quote_id as additional parameters in status responses for our quote post support. Our quote_id is, well the id of the quoted post, and quote an inlined rendering of the quoted post similar to how reblog from vanilla MastoAPI works. Notably these additional fields are directly in the top-level namespace of the statuses, not in the akkoma or pleroma sub namespaces like most other extensions. Presumably it was assumed, since it mirrors existing reblog semantics, vanilla Mastodon would use the same layout if it ever gains quote support in the future.

Recent’ish vanilla Mastodon actually added support for quote posts, but with a bespoke "quote authorisation" mechanism. Predictable now a quote parameter was added to status responses, but it is not just an inlined rendering of a status, but a special new object also containing information about the "authorisation" status of the quote.

See https://docs.joinmastodon.org/client/quotes/ and in particular https://docs.joinmastodon.org/entities/Quote/ and https://docs.joinmastodon.org/entities/ShallowQuote/
(i would have liked to add a full JSON response for a vanilla Mastodon quote post, buts it’s actually not easy to even find a Mastodon quote post in the first place)

This means, we’re likely to run into compat issues with vanilla Mastodon clients soon™. However, we cannot just swap our format over to match Mastodon’s either since this would break all existing clients using the established *oma response format for quotes.

Not sure what the best path forward here is.

(Note this is not about creating quote posts or supporting the quote ""authorisation"" mechanism, only about how existing quote posts are encoded in API responses)

We long had `quote` and `quote_id` as additional parameters in status responses for our quote post support. Our `quote_id` is, well the `id` of the quoted post, and `quote` an inlined rendering of the quoted post similar to how `reblog` from vanilla MastoAPI works. Notably these additional fields are directly in the top-level namespace of the statuses, **not** in the `akkoma` or `pleroma` sub namespaces like most other extensions. Presumably it was assumed, since it mirrors existing `reblog` semantics, vanilla Mastodon would use the same layout if it ever gains quote support in the future. Recent’ish vanilla Mastodon actually added support for quote posts, but with a bespoke "quote authorisation" mechanism. Predictable now a `quote` parameter was added to status responses, but it is **not** just an inlined rendering of a status, but a special new object also containing information about the "authorisation" status of the quote. See https://docs.joinmastodon.org/client/quotes/ and in particular https://docs.joinmastodon.org/entities/Quote/ and https://docs.joinmastodon.org/entities/ShallowQuote/ *(i would have liked to add a full JSON response for a vanilla Mastodon quote post, buts it’s actually not easy to even find a Mastodon quote post in the first place)* This means, we’re likely to run into compat issues with vanilla Mastodon clients soon™. However, we cannot just swap our format over to match Mastodon’s either since this would break all existing clients using the established \*oma response format for quotes. Not sure what the best path forward here is. *(Note this is not about _creating_ quote posts or supporting the quote ""authorisation"" mechanism, only about how existing quote posts are encoded in API responses)*

Oneric added the

pleroma_api

label

2025-11-14 23:32:35 +00:00

Oneric referenced this issue

2025-11-30 00:46:04 +00:00

Upgrade MastoAPI baseline (compatible Mastodon version) #1027

Oneric added the

mastodon_api

label

2025-11-30 15:53:50 +00:00

Oneric referenced this issue

2025-12-08 00:26:41 +00:00

[Tracker] MastoApi V2 compatibility #1030

Oneric commented

2026-02-04 00:24:59 +00:00

Author

Owner

As pointed out in this comment, there’s no overlap between the keys of "status" and the new "(shallow) quote" objects and we can hack in compatibility for both response formats by just filling out quote with a full "status"-type MastoAPI object like we do atm, but additionally set the two fields used in Mastodon’s quote response format:

{
 "state": "accepted",
 "quoted_status_id": "A2oU6jjKqcUmPDXzgt",
 … (all the regular "status" fields)
}

To avoid too much duplication and bloat we can probably just stick with always using the "shallow" format with just quoted_status_id instead of a full quoted_status sub-object.

("accepted" is ofc not necessarily technically correct if the quoted post comes from an instance performing manual approvals, but needed for client API compatibility)

As pointed out in [this comment](https://issues.iceshrimp.dev/issue/ISH-871#comment-019c24ed-c841-7de2-9c69-85e2951135ca), there’s no overlap between the keys of "status" and the new "(shallow) quote" objects and we can hack in compatibility for both response formats by just filling out `quote` with a full "status"-type MastoAPI object like we do atm, but additionally set the two fields used in Mastodon’s `quote` response format: ```json { "state": "accepted", "quoted_status_id": "A2oU6jjKqcUmPDXzgt", … (all the regular "status" fields) } ``` To avoid too much duplication and bloat we can probably just stick with always using the "shallow" format with just `quoted_status_id` instead of a full `quoted_status` sub-object. (`"accepted"` is ofc not necessarily technically correct if the quoted post comes from an instance performing manual approvals, but needed for client API compatibility)

Oneric commented

2026-02-05 21:14:15 +00:00

Author

Owner

To avoid too much duplication and bloat we can probably just stick with always using the "shallow" format with just quoted_status_id instead of a full quoted_status sub-object.

Nope. Tusky, the first client I know actually using Masto quotes, only handles non-shallow quotes (thanks to kopper for pointing this out), meaning we unfortunately need to dupe the whole object :\

THis is particularly bad since it inlines the author as account and the account contains full nodeinfo in akkoma.instance.nodeinfo.

Surveying common frontends and clients it appears only akkoma-fe is making use of akkoma.instance atm and it only uses nodeinfo.software and other toplevel instance keys (name and favicon). We can probably trim nodeinfo down to just version and software by default and add a config toggle to skip trimming as a quick fix if it turns out there’s a client currently using more than that. (The config should lead to a warning likeskip_thread_containment: false does. If nobody reports any issues 2 or 4 releases later we can drop the setting)
This would then also address #827 but overall a bunch of duplication remains making this still rather bloated.

Ideally (well, as ideal as it can be with this conflict already in place) all clients will slowly migrate to the Mastodon format allowing us to eventually drop one copy.

> To avoid too much duplication and bloat we can probably just stick with always using the "shallow" format with just quoted_status_id instead of a full quoted_status sub-object. Nope. Tusky, the first client I know actually using Masto quotes, [only handles non-shallow quotes](https://codeberg.org/tusky/Tusky/src/branch/develop/app/src/main/java/com/keylesspalace/tusky/entity/Quote.kt) *(thanks to kopper for pointing this out)*, meaning we unfortunately need to dupe the whole object :\ THis is particularly bad since it inlines the author as `account` and the account contains full nodeinfo in `akkoma.instance.nodeinfo`. Surveying common frontends and clients it appears only akkoma-fe is making use of `akkoma.instance` atm and it only uses `nodeinfo.software` and other toplevel `instance` keys (`name` and `favicon`). We can probably trim nodeinfo down to just `version` and `software` by default and add a config toggle to skip trimming as a quick fix if it turns out there’s a client currently using more than that. (The config should lead to a warning like`skip_thread_containment: false` does. If nobody reports any issues 2 or 4 releases later we can drop the setting) This would then also address #827 but overall a bunch of duplication remains making this still rather bloated. Ideally *(well, as ideal as it can be with this conflict already in place)* all clients will slowly migrate to the Mastodon format allowing us to eventually drop one copy.

Oneric referenced this issue from a commit

2026-02-07 16:31:28 +00:00

api/statuses: provide polyglott masto-and-*oma quote object

Oneric referenced this issue from a pull request that will close it,

2026-02-07 16:52:34 +00:00

Mastodon-flavour (read) quotes API compat #1059

Oneric referenced this issue from a commit

2026-02-07 20:12:02 +00:00

api/statuses: provide polyglott masto-and-*oma quote object

Oneric referenced this issue from a commit

2026-02-07 21:08:00 +00:00

api/statuses: provide polyglot masto-and-*oma quote object