reply filtering mark 3
(because the third try is the right try, right???)
Closes #1029 (closed). Closes #1081 (closed).
The original method, thread containment, attempted to solve the thread as a graph. If the thread was completely satisfiable, without cycles, the candidate message would be included in a timeline. This ultimately was deemed inefficient.
In MR !1437 (closed), @alex.s made another attempt using the recipients
column from the activity log table, which is an IR-specific property that is used to accelerate calculating recipient lists.
This approach had other flaws, but playing with it, I realized that if we used the <@
operator with a calculated array, we could efficiently filter against a second column in the activity log table that only contains User.ap_id
entries.
This MR introduces a simplified method that does the right thing, instead of doing all sorts of wankery with CASE
statements, we simplify the logic over !1437 (closed) to a simple OR
conditional.
In theory this type of design should have minimal overhead verses skip_thread_containment=true
, but some real-world performance data will be included once available.
We expand the tristate filter preference introduced in !1437 (closed) (none
, self
and following
) for reply filtering, to allow for full flexibility:
-
none
: display all replies always, regardless of whether or not a thread is broken (like GNU Social) -
public
: display all public replies, hide non-public replies where the thread is likely unresolvable (basically like old Pleroma with thread containment, but not as accurate) -
following
: display only replies to other people you follow (like Mastodon) -
self
: display only your own replies