automated slowmode
based on current rate of message change slowdown accordingly, if slowmode has been recently set manually don't override
Author: atmois
I uhh agree with this!!1!!!!111!
I AGREE
+++ good idea
https://github.com/allthingslinux/tux/issues/214
Super yes! i think that it would take a bunch of pressure off of the mod team in general. Although, it would be wise to have an option to override or turn off the dynamic slowmode just in case something needs to be changed.
def, please add
Working on it
ill assign myself and throw myself at this
here is a nice algo someone found in ATL @cherryl1k
Yes, modeling your channel “load” as a point in a 2D space—x = msgs/s, y = avg. message length—and defining a vector field that “pushes” that point back toward a neutral origin is a valid control‐theory approach. By following the gradient of a potential function, you can compute a Δslowmode delay that nudges traffic back to baseline.
Key considerations Potential function P(x,y): e.g. P(x,y)=½[(x/α)²+(y/β)²] ∇P=(x/α², y/β²) gives direction and magnitude of “overshoot.” Control input is 1D (slowmode seconds), so project ∇P onto a scalar: Δdelay = –k·(w₁·x + w₂·y) choose weights w₁,w₂ so msgs/s vs. length scale sensibly. Smoothing & stability: Use exponential moving averages for x and y. Limit Δdelay per minute to avoid oscillation. Clamp slowmode between 0 and Discord max (21600s). Additional metrics: Active user count, bot ratio, spam flags. May boost your decision function’s accuracy.
Simpler alternative Compute load L = w₁·EMA(msgs/s) + w₂·EMA(avgLen) Define thresholds T₀<T₁<…<Tn each mapping to a fixed slowmode value Hysteresis: only change when L crosses a threshold by a margin
Conclusion Your gradient/vector‐field idea is sound as a proof of concept, but in practice you’ll need parameter tuning, smoothing, rate-limit guarding and possibly simpler thresholding or a PID loop to ensure stability and predictability.