Add per-channel rate-limit for items plugin

[gdude2002]

To stop people spamming the hell out of it.

[gdude2002]

Or perhaps per-protocol/etc.

[rakiru]

I was considering writing a decorator to limit uses per user/channel/protocol/whatever, but that was more for commands that use an API that has limits, and thus has hard limits. Perhaps a plugin for this would be good? Use a pre-command event, and have a config for command limitations.
I'd still do the decorator thing for hard-limits (like lastfm), but that's what I do to avoid spam and stuff.

[gdude2002]

I want to at some point shunt some things to the .plug files so this might
be a handy thing start with if we're going to use decorators for this king
of thing properly.

Either way, both approaches should work.
On 24 Apr 2014 23:01, "Sean Gordon" [email protected] wrote:

I was considering writing a decorator to limit uses per
user/channel/protocol/whatever, but that was more for commands that use an
API that has limits, and thus has hard limits. Perhaps a plugin for this
would be good? Use a pre-command event, and have a config for command
limitations.
I'd still do the decorator thing for hard-limits (like lastfm), but that's
what I do to avoid spam and stuff.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-41338192
.

[rakiru]

This doesn't seem like the kind of thing to put in .plug files really. This is either something that a user should be able to change (and .plug files are not configs), or it's some limit that should be programmatically stuck to (such as an API rate limit, which could be enforced by command usage).

I think we should have some sort of config for rate-limiting commands on a per-user/channel/protocol/global level (either via plugin (what I'd do) or straight in the bot (seems unnecessary)), and decorators for those more technical limits.

[gdude2002]

Yeah, we should have both of those.

[gdude2002]

Right now this uses @rakiru's rate-limiting decorator. This is not even close to what that decorator is for, so we should create a proper one.

[rakiru]

I'm (slowly) working on protect, which has configurable command rate limiting. I think having it in a plugin is the only real way to allow users to set it up as they want, rather than having it hardcoded into a plugin based on an arbitrary amount that the developer thought was a good idea at that time. I might try to prioritise this part and get it out the door, before finishing the rest of the plugin.

One thing I'm undecided about, and unsure how to implement anyway, is a way to allow plugins to suggest default rate limits if Protect isn't used/configured. The first issue is how to go about doing that without it being messy. The second issue is how it would be done. Rather than having everything set a default rate, I think it would be better if we had different levels, and they can register their default level. For example (random numbers), we could have LOW as "1 call per second", MEDIUM as "1 call per 5 seconds" and use that as default, and HIGH as "1 call per 30 seconds". This way, there aren't really any arbitrary numbers being set by developers, but a consistent system where expensive/spammy commands have a higher rate limit than those that are less so. If a plugin has specific rate limiting needs, it's most likely due to API restrictions or similar, in which case it should be using the RateLimit decorator or TokenBucket (if I've actually pushed that). The alternative would be to completely ignore that and just have a one-size-fits-all default rate limit unless the user has configured it otherwise (example config for Protect could come with sane defaults for base and contrib plugins).

[gdude2002]

TokenBucket? I'd guess not, haven't seen it.

I think levels could work, though I think five levels might be a bit better. Shove it in an enum somewhere, and let users configure what they mean. Seems like the best way to do this, right?

Obviously, this means we'll be including Protect with the default plugin set, but I think that's a good idea regardless - that should help you out with your default level designation stuff as well.

[rakiru]

As I said, I was just giving those level as an example, not as what I'd be doing. I also said (or at least implied) that they would be user configurable - that's the whole point of not hardcoding numbers in plugins.

And yes, Protect is a default plugin. It includes important functionality that most users are likely to want.