Flood and Raid Protection

Introduction

Flood and raid protection defend a group against two related problems: a single member posting messages faster than anyone can read, and a coordinated wave of accounts joining at once to overrun the chat. Both are handled automatically, but only after an admin turns them on. Every feature described here is off by default and takes no action until it is enabled for the group, so adding the bot never changes how your chat behaves until you decide it should.

The two systems work at different points. Anti-flood watches individual members as they post. Anti-raid watches the rate at which new members join. Together with the manual /panic control and the known-abuser check on join, they give admins a way to keep a group readable during a spam burst and to shut the doors during a coordinated attack.

Anti-flood: message velocity

Anti-flood limits how many messages a single non-admin member can send in a short window. It is controlled by three settings in the group dashboard:

• set_antiflood_enabled — the on/off switch. Off by default.
• set_antiflood_msgs — the message limit. Default 8.
• set_antiflood_secs — the window length in seconds. Default 5.

With the defaults, a member who sends more than 8 messages within a 5-second window trips the limit. The bot counts each member's messages inside a short rolling window; when the count goes over the limit, the messages that made up the burst are deleted and enforcement begins.

Enforcement escalates. The first time a member floods, the bot applies a temporary mute of 5 minutes. If the same member floods again a short time later, the bot bans them instead. This means a one-off accident costs only a brief mute, while a member who keeps flooding is removed.

Two rules keep this fair and safe:

• Admins are exempt. The velocity check only runs for non-admin members, so moderators and admins are never muted or banned by anti-flood.
• It fails open. The counter runs against a fast in-memory store. If that store returns a transient error, the bot lets the message through rather than punishing it. A temporary infrastructure problem never results in an unfair mute or ban.

Anti-flood runs on the per-message hot path, so it reacts as messages arrive, before the heavier content checks. Because the threshold and window are configurable, you can tune it to your group's normal rhythm — a busy chat may want a higher message limit, while a quiet announcement channel may want a stricter one.

Anti-raid: join surge lockdown

Anti-raid watches how quickly new members join. It is controlled by four settings:

• set_antiraid_enabled — the on/off switch. Off by default.
• set_antiraid_joins — the join limit. Default 10.
• set_antiraid_secs — the window in seconds. Default 30.
• set_antiraid_lockdown_secs — how long the lockdown lasts. Default 600 seconds (10 minutes).

With the defaults, more than 10 members joining within 30 seconds triggers a lockdown. When that happens, the bot locks the whole group by removing the default chat permissions, so members can no longer post. The lock stays in place for the lockdown period and then releases automatically, restoring the group's normal permissions.

The lockdown is a pause, not a purge. It stops the flood of new accounts from posting while the surge is happening, giving admins time to see what is going on. When the timer elapses, the group reopens on its own. Like anti-flood, the join counter fails open — a transient error while counting joins never triggers a lockdown by mistake.

Manual lock: /panic and /unpanic

Admins can lock a group by hand at any time, even when automatic raid detection is turned off:

• /panic — immediately locks the group for the configured lockdown window. Members cannot post until it releases or an admin lifts it.
• /unpanic — releases the lock early and lets members post again.

Both commands are admin-only; a non-admin who runs them is refused. /panic is useful when you can see trouble starting and want to shut the group before the automatic threshold is reached, or when you have left auto-detection off but still want a one-command emergency stop.

Kicking known abusers on join

The setting set_kick_known_abusers (off by default) checks each new member against the network's shared user-intelligence signal. Accounts that have already been flagged as known abusers elsewhere on the network carry a global marker. When this setting is on and a flagged account joins, the bot bans it on sight, before it can post.

This check also fails open: if the abuser lookup errors out, the bot treats the joiner as clean and lets them in, so a lookup problem never bans a legitimate member. When a known abuser is banned this way, the event is recorded in the group's moderation log if one is configured.

How lockdown coordinates with night mode

Anti-raid and night mode both work by locking the group's send permissions, so they share the same underlying lock. The two features coordinate so that one never unlocks the group while the other still wants it shut. If a raid lockdown ends while night mode's quiet window is still active, the group stays locked for night mode; if night mode's window ends while a raid lockdown is still running, the group stays locked for the raid. The group only reopens once neither feature needs it closed.

Best practices

• Start with the default thresholds and adjust only if you see false triggers or misses. The defaults suit most groups.
• Keep /panic in mind as a manual backup even if you enable automatic raid detection — it is the fastest way to freeze a group.
• Turn on the known-abuser check for public groups that anyone can join; it stops repeat offenders before they post.
• Remember that admins are never affected by anti-flood, so test the feature with a non-admin account if you want to see it act.

Summary

Flood and raid protection give admins layered control: anti-flood handles a single noisy member with a delete, a mute, and then a ban; anti-raid handles a join surge with a timed group lock; /panic gives a manual override; and the known-abuser check stops flagged accounts at the door. All of it stays off until you enable it, all of it exempts admins where relevant, and the automatic checks fail open so a temporary error never punishes an innocent member.