Reply Wait Timer

[Nori]

Y'know how every member has a secret timer (like 15 seconds? for regular members and less or none for staff) before they're able to post again? Is there either
A) a plugin to adjust this timer, or
B) a way to introduce a wait timer on select boards?

I have seen the Post Timer but that is not a wait timer -- it is an automatic submission timer which is the opposite thing.


Example use, a fun competitive 'spammy' thread. Unfortunately it's unfair for staff to participate because they are not rate limited like members so inherently outcompete.

[Chris]

Dec 12, 2023 8:04:50 GMT -8 Nori said:

Y'know how every member has a secret timer (like 15 seconds? for regular members and less or none for staff) before they're able to post again? Is there either
A) a plugin to adjust this timer, or
B) a way to introduce a wait timer on select boards?

I have seen the Post Timer but that is not a wait timer -- it is an automatic submission timer which is the opposite thing.


Example use, a fun competitive 'spammy' thread. Unfortunately it's unfair for staff to participate because they are not rate limited like members so inherently outcompete.

"JavaScript is well suited to decorate the Christmas tree but not as suited to protect the gifts underneath the Christmas tree"

I believe there is a plugin that does a per-thread-based rate limit installed on this forum^[1], and that is made possible since the metadata offers a [first_post_id], [last_post_id ] and a [last_post_time ] on every page of the thread. This request seeks a solution that would enforce a rate limit on a per-user basis rather than a per-thread basis, which presents one particularly problematic obstacle.

As for plugins in general, the usual obstacles apply:

• ineffective against mobile users
• ineffective on those savvy enough to circumvent codes that is forced to run only run in the browsers and not on the server where it would be protected from any intervention.

In addition to that, there is no reliable way to determine the last time a particular user posted within a particular thread in order to do any calculations on whether they are within some allotted timeframe. If a user posts on page one and then finds he's on page two on a subsequent post, the timestamp from page one would no longer be available for any calculations. Half-measures or cumbersome/forbidden methods to overcome such an obstacle do exist but are far from ideal.

The easiest would be some sort of cookie/localStorage marker that keeps a record of the last post, time, and thread made by the user and then uses that in the calculation when the information is unavailable. That is obviously easily circumvented with the user clearing cookies or switching devices or browsers (including going into incognito mode) where no such cookie exists or simply just using mobile.

Another option might be to use a plugin key to keep a record of the last post, time, and thread. The key would have to be writeable so the time and post can be recorded, meaning the user can also overwrite that data with their own chosen post, time, and thread. There's also the issue with near-simultaneous key operations where recorded information might slip through the cracks, resulting in a plugin that "sometimes works" even when the mobile aspect is removed from the performance evaluation.

There exists an AJAX call that returns all posts made within a thread by a specific user, and you can see it in operation when clicking the on the search bar when viewing a thread and selecting the Posts Created By filter. That would indeed give you the necessary timestamp for your calculations, but that is a request to the server that is expressly forbidden for use within plugins unless you acquire a user action to send such a request. That means the plugin would need to present some sort of UI for the user to acknowledge they want the request sent, then await the reply to such a request, decode and query the reply data for the information you seek, and finally calculate the time difference with that information, at which point it might all be moot since the time spent doing all that would probably be longer than the rate limit that we're trying to enforce. The server is now being bombarded with moot requests that accomplish nothing and directly affect all PB users due to a lack of resource conservation.

I would suggest the iron-clad solution would be to require staff members who are not rate-limited to switch to a secondary account if wishing to participate in thread games where rate-limit or the lack of one presents an unfair advantage or install the per-thread rate limiting plugin.

The plugin is not impossible but...

[Nori]

Ah! I somehow never received a notification of a reply ^^;
Thank you for the response Chris <3

Per user wouldn't be bad. There's never really a reason for any staff on a regular basis needing to post more often than once every 15 seconds. But yeh that all seems quite a hassle. Are you aware of any reasoning for why this is in the first place?

The plugin obstacles aren't a concern. It's all low-stakes fun games. The unfairness introduced by the staff vs non-staff is more impactful than some edge cases (not that this is a huge deal at all ^^). Would be an annoyance, confusing, and a hassle to require staff to change accounts just to play a game on a 1-acct per person site.

This addresses my question though, thanks again for the reply! Sorry for my delay.