Cap serving response to /gamble

[arkits]

just like real life, /gamble has become addictive and spammy.
need to put a cap on how many times a user can /gamble.

[arkits]

ideally this implementation would support capping other commands also.

[vcidst]

We can implement a command history object for last N commands that stores command name, invoker's username and datetime. Whenever a new command needs to be handled, we just check command history for last command invoked by the specific user

[vcidst]

We should also consider variable cost of /mom and /gamble. If someone has already called three /mom in a row -- they should be paying a significantly higher price for the last one.

This can be implemented with a command history.

1. Get time intervals between last three (magic number, could be anything) command calls
2. Hold their average time as t
3. Calculate the cost of command from a damping function like ( e^(-t/A) where A is the time constant)

[arkits]

in that case we can implement a history element in each Bakchod...

{
    id = 123,
    username = "pahagwl",
    rokda = 2002,
    history = {
        gamble = <Date when last gambled>,
        mom = <Date when last momd>
    }
}

[vcidst]

in that case we can implement a history element in each Bakchod

What happens if pahagwl is active in 5 chaddi enabled groups? Will it hold the last gamble in either groups or do we add a chat_id field somewhere too?

I think a separate command_hist class will serve better as it can be extended to any command easily. It can also handle different groups by having a chat_id field with each command call.

[vcidst]

Good time to connect redis to chaddi

[arkits]

What happens if pahagwl is active in 5 chaddi enabled groups? Will it hold the last gamble in either groups or do we add a chat_id field somewhere too?

Considering rokda is shared across groups, then gambling and other rokda related transactions should be capped across groups as well?