search

eazar001 / yesbot

IRC Bot Written in Prolog
MIT License
19 stars 5 forks source link

yesbot needs an anti-repeat #37

Closed Anniepoo closed 8 years ago

Anniepoo commented 8 years ago
and amplifying the power of that in a flexible way. that way taking advantage of the host language - Anniepoo is staring at an arduino and some servers and feeling ennui i don't see any abstractions for joins or anything though =\ that sucks, kind of defeats the purpose ... (for the lua datalog) www.swi-prolog.org currently appears to be down. Please be patient until the matter is resolved. - OndraG (~Ondra@ip-78-45-127-96.net.upcbroadband.cz) has joined - L8D has quit (Ping timeout: 272 seconds) - OndraG has quit (Quit: Leaving.) www.swi-prolog.org currently appears to be down. Please be patient until the matter is resolved. www.swi-prolog.org currently appears to be down. Please be patient until the matter is resolved. www.swi-prolog.org currently appears to be down. Please be patient until the matter is resolved. www.swi-prolog.org currently appears to be down. Please be patient until the matter is resolved. - oleo__ has quit (Quit: Verlassend) To prevent the above, I suggest an anti-repeat feature - right before text is said in channel (after any exensions) check to see if it's been said recently, either by holding a buffer of the last n lines said, or lines said in the last nn minutes. This protects the channel from a misbehaving plug in
eazar001 commented 8 years ago

This style of solution is a bit too much on the side of "defensive programming" for my taste. I can see cases where it would remedy a problem in one area, but cause undesirable side effects in others. There are certain cases for example, where repeats are desirable. In the case above, the problem was caused by a crashing thread. Masking this problem would probably be a bad thing in the long run. Nonetheless, the concept is a noteworthy consideration and probably needs to be considered in some kind of a "state architecture".

eazar001 commented 8 years ago

I've added the core "concern" of this issue to issue #12.

eazar001 commented 8 years ago

v1.2.0 and v1.2.1 both address this concern with a compromised solution. I think it's better that if a plugin misbehaves, then they be disabled within the channel or the bot prompt. This is precisely what these latest releases allow. Filtering messages based on a tracked buffer could have unwanted side-effects spill over into other plugins, or even worse ... mask the underlying problem of bad programming (incidentally bad programming on my part was responsible for this bug). Therefore, I think disabling the plugin until the developers can patch the problem would be my preferred approach.

I do think that yesbot needs to be controlled in terms of repetitions still ... but I'm more scared of users, rather than me. For instance, people flooding the bot with commands or valid input, is still a legitimate concern. Due to this possibility, I'll most likely implement a rate limiter based on the buffer proposal you made.

At any rate, v1.2.1 addresses this issue sufficiently in my view.