The usual story about Matrix moderation goes: someone opens a public room on a server with open registration, the spammers arrive, weeks of whack-a-mole follow, and the doors get closed. Open rooms die of this on community servers all over the federation, and most write-ups end with the retreat — "we locked registration, problem solved." That is the story where the community loses.
A Thousand Newlines, a three-part series by the operator of codestorm.net that finished September 19, is the other story. It is worth your time whether or not you run a Matrix homeserver, because the shape of the solution generalizes: community infrastructure held together by one person's unpaid labor is a liability even when it works — and the fix is to turn the fix into something others can run.
The wave¶
The attack, which ran for months starting in late 2025: more than six thousand accounts, originating from several hundred homeservers, hammering public rooms with spam. The operator's first responses — manual bans, then scripts good enough to mitigate spam as it happened — all failed the same test: they were reactive. The door was still open behind him. Part 2 is a fairly honest record of throwing things at the wall. Part 3 is where it turns.
The accidental vantage point¶
The turning point was an outage with nothing to do with spam. On September 2, 2025, matrix.org went down for 24 hours (post-mortem), and since Synapse's default notary server — the server other homeservers ask for other servers' signing keys — is matrix.org, every admin's logs lit up. The admins in the operator's Synapse-admins room did the sensible thing: add a few more trusted notaries. One of them, the admin of envs.net, added codestorm.net.
That made codestorm a notary for one of the largest public servers in the federation, and notary behavior did the rest: when a notary gets a key request it cannot answer, it fetches the key from the origin server and caches it. Synapse asks all configured notaries in parallel before contacting an origin directly. Result: codestorm was now passively learning signing keys for a huge slice of the federation — 26,824 distinct server names in the server_signature_keys table, versus roughly 13,000 in the destinations table his earlier scans had relied on. A better map, assembled for free, by being useful to someone else.
The pipeline¶
What he built with that map, in his own description, is glue:
- a script that pulls distinct server names from the keys table and runs them through the regchecker binary from the Meowlnir moderation project, flagging servers with dangerously open registration;
- a systemd timer running the scan every 10 seconds, with dedup so already-scanned servers aren't re-checked;
- automatic user-glob policies (
@*:spam-server.example) on every flagged domain, in a private ban list — chosen over room ACLs deliberately, because a user policy is invisible until executed, while an ACL event publishes the whole deny list into the room state where spammers can read it; - a weekly full rescan so servers that fix their registration get unbanned instead of being punished forever — the part that keeps an automated blocklist from curdling into an over-blocking blacklist;
- a notification room, which grew into the public policy list with 200+ subscriber accounts, most of them moderation bots shielding rooms across the federation.
Current state per the author: a bit over 900 servers on the list, offline ones auto-expiring after 60 days, new open-registration servers discovered daily, and the people behind the campaign still unidentified. This is not a small-scale demo — it is production moderation infrastructure for a corner of the open federation.
The honest part, which is also the lesson¶
The author then does the thing most successful community projects avoid: he audits his own success. The list worked because everyone trusted codestorm.net — his infrastructure, his uptime, his not-abusing-it. "It fully depends on me," he writes, and says the quiet part: he does not want that. Since June 2026 the scanning logic has been a maubot plugin (open source, mirrored to GitHub) with metrics and a Grafana dashboard, and the list now has scanning vantage points in several countries. If you do not want to trust his list, you run your own scanner from your own vantage point and do what you want with the output. His words: "no one should have to put that much trust in others."
This is the same problem every community stack runs into, wearing a Matrix costume. A moderation list, a DNS resolver, a backup target, a key directory — the moment one volunteer's server becomes load-bearing trust infrastructure, the bus factor is the vulnerability. The mature move is not to hoard the role; it is to make the role reproducible and hand out the build instructions. That is what happened here.
For your deployment¶
- If you run public rooms on open registration, decide the posture knowingly. "Close registration" is one answer; the codestorm series is evidence for the other one.
- If you keep public rooms: subscribe to an existing policy list you actually trust, or run the scanner yourself — the plugin makes the second option a drag-and-drop on a maubot instance most federation operators already have.
- If you ever run shared trust infrastructure of any kind, budget for the day you are the single point of trust, and build the export path on day one, not after the outage.
- The weekly rescan is not optional polish. Automated bans without a re-evaluation loop over-block fixed servers and eventually punish people who did nothing wrong.
One more reason to read it now: The Matrix Conference runs October 20–23 in Malmö — talks on the schedule cover community self-hosting and digital sovereignty directly. This series is a preview of what those rooms will sound like: not "Matrix is impossible to moderate," but "here is the boring machinery that made it workable."
Sources: A Thousand Newlines, parts 1, 2, and 3 (codestorm.net, Aug 21 / Sep 10 / Sep 19, 2026); This Week in Matrix, Sep 25; matrix.org outage post-mortem; Matrix-federation-scanner; Meowlnir.