whatsmeow-antiban: ported baileys-antiban's ban-risk mitigation (rate limiting, warm-up ramp, typing sim) to Go

[TA-rathnayaka]

whatsmeow is a bare protocol client on purpose, which is great, but it means anyone sending messages programmatically has to build their own rate limiting / warm-up / pacing layer or risk a ban. On the Baileys (Node) side, baileys-antiban already solves this well, so I ported its 11-gate design to Go for use with whatsmeow.

whatsmeow-antiban — ban-risk mitigation for whatsmeow bots:

• Per-minute/hour/day rate limits with jittered, human-like delays
• Multi-day warm-up ramp for freshly-linked numbers (no full volume on day one)
• WhatsApp 463 timelock + ban-signal recovery state machine
• Cold-outreach throttling (contact graph + topology scoring) and reply-ratio tracking
• Human-like typing simulation with time-of-day pacing

It's pure logic with zero external dependencies and no whatsmeow-specific types — you feed it JIDs/strings and wire BeforeSend/AfterSend around your own client.SendMessage calls, so it works with whatsmeow directly:

gate := antiban.NewGate(antiban.GateConfig{
    Preset:  antiban.Resolve("moderate"),
    Enabled: true,
    Now:     time.Now(),
})

delayMs, err := gate.BeforeSend(recipientJID, text, isGroup, sourceGroupJID, time.Now())
if err != nil {
    // blocked
}
time.Sleep(time.Duration(delayMs) * time.Millisecond)
// ... client.SendMessage ...
gate.AfterSend(recipientJID, text, isGroup, sourceGroupJID, wasNewChat, time.Now())

MIT licensed, 63 tests, go get github.com/TA-rathnayaka/whatsmeow-antiban. Feedback and issues welcome, especially on the parts of Record463/ban-signal classification that depend on the exact whatsmeow error shapes for these responses.

[masewo]

Nice. Thank you for the porting! Had the same idea. Maybe you can also describe in your repo which event handlers need be connected with which recording function. Would also prefer constants for the presets but that's a matter of taste.

[TA-rathnayaka]

Fair points, thanks for trying it out.

On event wiring — worth noting up front: only TemporaryBan actually comes through whatsmeow's event bus (→ Gate.RecordBanSignal("rate_overlimit", ...)). The 463/403 signals aren't events at all — they come back synchronously as the *whatsmeow.IQError from client.SendMessage itself, so you check iqErr.Code right after the send call, not in an event handler. I'll add a short table to the README mapping each recording function to where it's actually called from (event handler vs. inline after SendMessage) since that split isn't obvious from the API alone.

On constants — reasonable ask, will add a PresetName string type with exported consts (antiban.Conservative, antiban.Moderate, etc.) so Resolve still takes a string for config/env-var compat but callers get compile-time safety in code. Should be a non-breaking addition.