The bump_all_conversations task was only useful when support for
conversations were initially added and this task was dropped in
370d422a1d.
Fixes: #1125
The docuemnted config options only worked for the MastoFE version.
While at it, just allow all keys to be overriden by admins and
merge logic for both manifest variants.
Reported-by: Clovis <clovis@bdx.town>
The db setting for fuzzy GIN scans was added in
b6bb73f43e with the intention of
optimising full-text searches of posts and users at the cost of a
slight inaccuracy in results for edge cases of very common queries.
Indeed, this is the intended usecase of the setting as per its docs¹.
In practice however, it affects more than just FTS
and the consequences are much more jarring.
The setting affects _all_ GIN index scans, not just FTS-typed columns
specifically. Besides the post and user FTS indexes, our database
currently uses GIN indexes in the Oban table and for activities’
recipients. Thus on particularly busy servers this might screw with
job control. On all servers this will screw with results for anything
primarly scanning the recipient index. Whether this is the case depends
on the lanner and Postgres’ statistics. It most likely was the source
of incomplete and unstable results in the since removed DM timeline
(ref.: #798) and can
(due to overly coarse Postgres statistics) also happen for the
last-status query used in DM conversations.
In theory public and unauthorised timeline views may also scan
recipients for as:Public entries. In practice though, this value is so
common Postgres will most likely prefer any other sensible index or even
just perform a full table scan if there are no other restrictions.
Furthermore, even for FTS this limit already had very noticeable
and undesireable consequences. We heard from some servers about
their search results being seemingly random and changing slightly
to drastically on each reload. E.g. on akko.wtf search results
tended to add and remove a couple entries each reload for many queries.
On labyrinth.zone results often ended up mistakenly empty or only with
a (small) random subset of matching posts often completely different
between each query (with a non-empty result).
While optimising FTS is indeed the documented use-case of this setting,
the docs also recommend for a value "in the thousands" specifically
“5000 – 10000”, yet the value we used to enforce was but a tenth of this
range’s lower bound. Yet, even 10000 still exhibited some instability in
results albeit to a lesser degree than before. Thus just do not set this
by default at all. For servers which really need to limit FTS searches
for perf reasons and are willing to accept some instability in FTS
results, a new config option is provided to set this specifically
_only_ in connections performing a FTS search.
[1]: https://www.postgresql.org/docs/17/gin.html#GIN-TIPS
The last user of this acursed mess was dropped in the preceding commit.
The COALESCE_follower_addres index existed solely for activity_visibility.
Now nothing is blocking parallel restore of db dumps anymore
allowing significantly faste restores and removing the pitfall
of (when not following our old documented flgs) greatly _worsening_
restore times by enabling parallel mode.
Most of the major micro-blogging AP implementations do not make
votes or voter identity available to anyone by regular means.
However, this is but an informally adopted common practice.
Smithereen may (depending on the decision of the creating user)
disclose who voted and what everyone voted for. This information
is made publically available to everyone, including via ActivityPub
(eventhough the AP vote collections show some type and data
inconsistencies between the inline and standalone version at the
time of writing. It is necessary to fetch the standalone collections
for the full information.)
Smithereen does indicate whether a poll will disclose votes and voter
identies and when this is kept secret. But of course, for this info
to be visible to our users we will need to first pick up the hint
from Smithereen and forward it in our Masto API responses.
Example: https://friends.grishka.me/posts/1116518
Projects like e.g. Iceshrimp.NET and Pleroma already allow
setting and federate alt text for profile media.
Mastodon too recently added support for avatar and header descriptions
in https://github.com/mastodon/mastodon/pull/37634
and https://github.com/mastodon/mastodon/pull/38221.
We use Mastodon-compatible API parameters for avatar and headers and
extend the naming scheme for background images not found in Mastodon.
There’s one difference however: we do not actually store media alt text
when no matching media was yet set at all. Since media is stored as an
inline, AP-like JSON object, it can only exist if there’s an image.
Co-authored-by: Oneric <oneric@oneric.stub>
Sometimes changes aren’t picked up automatically,
so document an easy way to force it.
We don’t want to force an ANALYZE on each migration since this
just wastes time on new installs and for those whose planner
already picks it up anyway.
The advertised file no longer exists, probably since
the backend repo stopped carrying a precompiled frontend.
Also highlight options for custom commit URLs.
Elixir 1.19 now requires (with a deprecation warning) return_diagnostics
to be set to true for parallel compiles. However, this parameter was only
added in Elixir 1.15, so this raises our base requirement.
Since Elixir 1.14 is EOL anyway now this shoulöd be fine though.
It only served for a niche, admin nice-to-have informational stat
without too much value but was unreasonably costly to maintain
adding overhead with multiple queries added to all modifications
to the fairly busy activities table.
The database schema of the counter table and the activity_visibility function
used for counter updates also did not know about "local" visibility (nor the
recently removed "list" visibility) and misattributed them to the "direct" counter.
On my small instance this nearly halved the average
insert time for activiteis from 0.926 ms to 0.465 ms.
No known client ever used this. Currently among akkoma-fe, pleroma-fe,
Husky, Mangane and pl-fe only the latter acknowledes the existence of
the in_reply_to_conversation_id paramter in its API definitions,
but even pl-fe does never actually use the parameter anywhere.
Since the API parameter already was converted to DMs internally,
we do not need to make special considerations for already existing
old conversation-addressed posts. Since they share the context they
should also continue to show up in the intended thread anyway.
The pleroma.participants subkey mentioned in docs did already not exist
prior to this commit. Instead the accounts key doesn’t automatically update
and this affects conversations retrieved from the Mastodon API endpoint too
(which may be considered a pre-existing bug).
If desired clients can already avoid unintended participant additions
by using the explicit-addressing feature originally introduced in
https://git.pleroma.social/pleroma/pleroma/-/merge_requests/1239.
With the above-mentioned feature/bug of conversation participants
not updating automatically it can replace almost everything
conversation addressing was able to do. The sole exception being
creating new non-reply posts in the same context.
Neither conversation addressing nor explicit addressing
achieves robust, federated group chats though.
Resolves: #812
This feature was both conceptually broken and through bitrotting
the implementation was also buggy with the handling of certain
list-post interactions just crashing.
Remote servers had no way to know who belongs to a list and thus
posts basically showed just up as weird DM threads with different
participants on each instance. And while on the local instance
addition and removal from a listed grated and revoked post
access retroactively, it never acted retroactively on remotes.
Notably our "activity_visibility" database function also didn’t
know about "list visibility" instead treating them as direct messages.
Furthermore no known client actualy allows creating such messages
and the lack of complaints about the accumulutaed bugs supports
the absence of any users.
Given this there seems no point in fixing the implementation.
To reduce complexity of visibility handling it will be dropped instead.
Note, a similar effect with less federation weirdness can already be achieved
client-side using the explicit-addressing feature originally introduced in
https://git.pleroma.social/pleroma/pleroma/-/merge_requests/1239.
Ref: #812
Markdown requires an indentation of 4 for a following paragraph to
continue a list item. Previously, the continuing paragraphs were only
indented by 2 spaces, leading to the list being interrupted and
numbering restarted each time.
Split into scheduled (intentionally delayed until a later trigger date)
and available (eligible for immediate processing but did not yet start).
This will help in diagnosing overloaded instances or too-low queue
limits as well as expose configuration mishaps like
#924.
(The latter by violently crashing the telemetry poller process while
attempting put_in for a non-configured queue creating well visible logs)
Even if --keep-threads is used, replies of
pinned posts might still be pruned as documented
for this option.
Thus keep-threads is no reason to skip reply counter recalculation.
Presumably those inlined copies were added to avoid the need for queries
each time the info is needed. However, they tend to desync from the actual
activities for not yet fully understood reasons; see:
#956
As a workaround until the root cause is identified and fixed and/or
we no longer rely on the inliend copies add a mix task to regenerate
the inlined "cache" from the authorative activity data.
Does not yet deal with inlined emoji reactions
since its format is a pain to deal with.
No HTTP3/QUIC support yet.
Note, allowing both here means we don't actually profit from HTTP2 multiplexing
due to Finch(? or maybe a dependency of Finch?) limitations. But it means we can
now interact with HTTP2-only instances (if such exist) and still may get minor
gains from header compression etc
Adventurous admins can change the config to allow only HTTP2,
thus profiting from multiplexing (but breaking federation with
HTTP1-only instances which are in fact observed to exist).
The next Tusky release is going to remove support for the v1 filters API,
see: https://codeberg.org/tusky/Tusky/pulls/5215.
Since Akkoma doesn't support the v2 API this
could cause significant issues for Akkoma users.
And improve monitoring documentation in particular
more detailed instructions for setting up Prometheus
metric scraping and the reference Grafana dashboard.
Added in Mastodon 2.9.2 (June 2019) this is plain-text-only and supposed
to be shorter compared to the older description field.
Some clients were reported to require this field to properly function.
Reported-by: https://akkoma.dev/paulyd
