How the project is split
BonkerBot is published in two halves, and the line between them is deliberate.
| Public | Private | |
|---|---|---|
| What | The bot — commands, moderation flows, appeals, trust maths, scoring, storage, UI | The pattern library — what the bot actually looks for |
| Why | So anyone can audit how the bot treats people | So scammers can't read the rules they need to bypass |
| Contributions | Welcome | Closed |
The public half: how it treats people
Everything that governs consequences is open, because that is the part you have a right to check before you let a bot moderate your community.
That includes the scoring engine and its corroboration floor, the trust score and every path that can change it, all the thresholds, the mod review flow, the appeal system, the undo paths on every automated action, the audit logging, the retention and deletion logic, and the whole command surface.
If your worry is "what will this bot do to my members and can I see it coming" — that question is fully answerable from the source.
The private half: what it looks for
The detection patterns are not published and will not be.
A published detection list is a bypass checklist. Scammers iterate on their copy faster than anyone else on the platform; handing them the rule set turns a detection tool into a free QA suite for the next campaign. Worse, it degrades enforcement quality — the reason we can say why an account was actioned is that the pattern that caught it is still worth something. Publish it and the honest answer to every appeal becomes "it doesn't match anything any more."
This is how every anti-fraud system on the internet works, for the same reason. We'd rather state the tradeoff than pretend it doesn't exist: you cannot audit our scam list. You can audit everything that decides what happens to someone once it matches.
Contributing
Contributions to the public half are welcome, and that's most of the bot: commands, embeds and UI, setup flows, i18n, accessibility, database and performance work, tests, documentation, bug fixes.
What can't be taken as a contribution is a detection pattern. Not a judgement on the contribution — pattern changes have to go through the private review path, because a scam rule that arrives through a public pull request has already been published by the time it's reviewed.
Self-hosting: bring your own patterns
The published code runs. It does not ship with our pattern library, so a self-hosted instance starts empty and you supply your own detection rules. The training tools are included; the patterns are not.
A self-hosted instance is not connected to our trust network. It cannot read our global scores and it cannot write to them. This is the part people are usually surprised by, so here's the reasoning:
The trust score is only worth anything if the reports feeding it can be trusted. We have no way to validate what an instance we don't operate sends us — the code is modifiable by definition, so a self-hosted bot can be edited to report whatever it likes. Accepting that data would mean anyone could run a modified instance and mass-poison the reputation of accounts they dislike, across every server on the network. There is no verification scheme that fixes this, so we don't accept the data at all.
So a self-hosted BonkerBot is a genuinely capable local anti-scam bot with its own local reputation scores. It is not a member of the network, and it is on its own. That's not a paywall — it's the only honest answer to "we can't check if this is true."
Full instructions: Self-hosting.
Where it runs
The hosted bot runs on infrastructure operated by Orange Cat Associated, and will move to a sharded deployment as it grows. Message processing — pattern matching, OCR, image hashing, the optional similarity layer — happens on that infrastructure. No message content is sent to any third-party API. There is no such call in the pipeline.
See What the bot can see for the mechanical detail.