Feature Request: The One-Post Problem

[pskfyi]

Motivation

With the rise of Discord, brigading has become an increasingly common occurrence throughout 4chan, especially on /pol/. The most prominent form of abuse has been what we call one-posting, where a user (typically a memeflag but not always) posts a single controversial image then abandons the thread.

Proposal

Allow users to filter threads based on the number of replies the OP has posted in their thread, defaulting to 0. (That is, hide no threads by default.) Expose a number input to allow users to configure this threshold value.

There are other issues here. OPs can get around this with very trivial posts, and sophisticated brigadiers will learn to circumvent this if it becomes widely-used. But solving these is a much bigger problem for a separate issue.

[pskfyi]

I am willing to attempt a PR for this if it is deemed acceptable. We would first need to determine where to expose the control. As this feature would make it very easy to hide all new threads, the UX ramifications need to be considered as well. It may be wise to marry this setting with a minimum number of total replies before the threshold kicks in. For example with a threshold of 1 (at least one OP reply required) and a 50-reply minimum, only threads with more than 50 replies would be subject to the threshold. This is simply an example and has not been fully thought through.

[ccd0]

Main issue is that there's no way to get the information without downloading all the threads on the board.
4chan/4chan-API#54

[pskfyi]

Thanks for taking the time to reply and for opening the ticket for the API. I mistakenly believed that this information was in the catalog payload. I thought it was the case that the present filter option op:no would hide whole threads if a reply matched the filter regex, but clearly that is incorrect.

It feels like it would be an abuse of the official API to make it easy for users to fetch all threads at once. On the other hand, it spares the official APIs from serving the images in undesirable threads which would be hidable.

I see that the catalog endpoint returns a total replies count. We could leverage that to determine which threads to pre-fetch for further filtering. We could also enforce a sane minimum reply count to avoid abuse of the thread APIs.

Hypothetically, with the current application architecture: if thread information was pre-fetched on the catalog page, is it cached and available if a user opens that thread? Or would it be downloaded from scratch again?

[ccd0]

Hypothetically, with the current application architecture: if thread information was pre-fetched on the catalog page, is it cached and available if a user opens that thread? Or would it be downloaded from scratch again?

The browser would probably have the API data cached, but it would still have to download the HTML for the page.

[pskfyi]

The browser would probably have the API data cached

OK that's good.

Pre-fetching threads seems to have the potential to expand filtering capabilities tremendously. You could for example highlight all threads in which a specific tripcode user has posted. (*cough*Wayne*cough*)

But I'm not sure if this is within the scope of the extension. That's really your call.