Skip to content

reply filtering mark 3

kaniini requested to merge feature/reply-filtering-mk3 into develop

(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
Edited by kaniini

Merge request reports