Currently only affects MisskeyApiClient, as Mastodon-flavour API is
constraint by a server-side hard limit of 40 replies.
Prepares for implementing multi-part requests which will allow
Mastodon-flavour clients to also follow the same limits.
Akkoma offers the emoji_reactions field both in
the toplevel and in the pleroma namespace, to
achieve compatibility with fedibird’s frontend.
The current probing order will treat Akkoma as
a Fedibird instance. However, the relevant endpoint
emoji_reactioned_by returning more user details along with
reactions is currently not implemented in Akkoma.
(Only the minimal API viable for the frontend was implemented,
i.e. currently just the emoji_reations duplication
and PUT `/api/v1/statuses/:id/emoji_reactions/:emoji`)
Thus this order broke evaluation of emoji reactions for Akkoma
and even if all Fedibird API was implemented, limiting Akkoma
to Fedibird API may give suboptimal results.
However, fortunately this probing is only ever relied upon if the
ApiClient was manually initialised as Mastodon. If (as by default)
autodetect is used, Akkoma gets correctly identified as a
Pleroma variant and the probing-based guess isn’t used.
In practice this issues was likely rarely ever encountered.
Like in *key, *oma users can react with arbitrary emojis.
Unlike in *key, a single user can add multiple emoji reactions
to a single post and favouriting still exists as a separate concept.
By using only the Mastodon API for *oma, favourites still get
interpreted but emoji reactions aren’t taken into account at all.
Fix this by adding support for the relevant Pleroma APIs.
To avoid a bias towards fav+react or multiple reacts on a single post
and to be more similar to connection strengths in Mastodon and *key,
aggregate reacts and favs and count them only once per per user and
post.
It is not clear whether the existence of a non-empty
pleroma/emoji_reactions field in notes data already implies support for
the reactions API endpoint. It at least seems sensible and would allow
to skip the initial feature metadata check, but let’s stick to the safe
approach for now.
Fedibird also supports emoji reacts and (like Akkoma >= 3.2.0) provides
the emoji_reactions sections at the toplevel of notes with an array of
account IDs included for every reaction. At first glance Fedibird
doesn't seem to provide a /reactions API or similar with more detailed
user info directly included. Supporting Fedibird would thereofore
require additional user info lookups at the end.
This commit makes no attempt at supporting Fedibird or
taking advantage of the account_ids array for Akkoma.
Co-authored-by: Natty <natty.sh.git@gmail.com>
Fixes a mix-up from 15579d7e78.
Since replies are omitted from the gathered notes, this effectively
removed reply evaluation from Mastodon API, but instead added the
author of quoted posts as well as replies to the quoted post to the
circle.
