LOCKED DOWN!
Eight layers of protection, public audits, same-day disclosure, and one rule above all of it: nobody but you can touch your site. Not even us.
The rules, in the builder’s words
You are trusting this software with your life’s work. That earns you three promises, and they are not marketing — they are how the code is built.
I have no right to lock someone out of their site. That is a massive violation of their rights.
SnapSmack has no kill switch, no vendor login, no back door. When a site locks itself down after tampering, that lockout is local, triggered only by tampering on that site, and lifted only by its owner with their own password and 2FA. The network can warn you. It cannot act on your behalf, and we would not want it to.
We don’t hide important information from people who trusted us with their art. That is a violation of our duty of care.
Security findings, breaches, and audit results go public the day we have them. We don’t tell people they were hacked two weeks later when we can’t hide it.
The audits and the failures are both on this site, in full.
It’s a blessing to be trusted with someone’s most beautiful possessions. You honour them back. You don’t monetize them.
No analytics sold, no tracking pixels, no “anonymised” data deals. Your visitors are not counted by anyone but you. The full privacy position is on TWIG N BERRIES.
When something goes wrong
Every SnapSmack site watches its own files. Here is the chain, end to end, as it ran in a real test on 11 September 2026.
A file on the server changed and nobody signed it. Within minutes the site goes to LOCKOUT: public pages are protected, the admin shows exactly which file, and nothing is trusted again until the owner enters their password and 2FA and decides — restore the clean copy, or bless the change because it was theirs.
It caught our own developer dropping an unsigned file. That is the point.
The site reports the incident to SMACK CENTRAL. One site with one tampered file is a local matter. Several sites reporting tampering inside a short window is a different animal: a probable zero-day, someone working through the fleet.
Every SnapSmack owner is told, immediately: apply updates, take a backup, rotate keys and passwords, consider pausing federation until it’s understood. Then we publish what we know. Nobody’s site is touched. Everybody’s owner is informed.
Multiple SnapSmack sites have reported tampering in a very small window and we might be under attack. It means: apply updates, do backups, rotate keys and passwords, immediately.
What it does not mean: that anyone has taken your site offline. Only you can do that. Sean takes his own fleet off the fediverse when it’s his fleet that’s the risk. Yours is yours.
Eight layers of FAFO
The more work a troll or attacker has to do, the more likely they are to go bother someone else. Each layer is independent; each blog keeps control of its own thresholds and decisions.
Device fingerprinting, hashed identities, silent bans, keyword rules, and Akismet filtering protect each comment box without cross-site tracking or stored personal data.
Ban a troll on one site and the hashed ban propagates across your whole multisite fleet. The original identifying value never leaves the site that created it.
Opt-in reputation scoring combines reports from participating blogs, weights established sites appropriately, decays old incidents, and supports community correction.
The central reputation service coordinates threat scores and style vectors, but each blog retains control of its own thresholds and ban decisions.
Stylometric detection recognizes the writing habits of banned harassers who return with a new device, address, and email. Raw comments never leave your server.
Automated file-integrity monitoring catches tampering, locks down compromised public pages, alerts the owner, and reports confirmed incidents to the network so other owners can be warned.
Scanner rejection, a configurable private login route, aggressive failed-login bans, mandatory 2FA, and an independent break-glass recovery card harden the front door.
Cryptographically signed releases, published checksums, signed git tags, reviewed bundled dependencies, and public security audits protect the software supply chain.
The fair question
It’s a fair question and it deserves a straight answer, because federated software is a shared-trust arrangement: a hole in our code could become somebody else’s problem. So, three questions, answered plainly.
No. At any sign of trouble Sean takes his own fleet off the fediverse first and asks questions second, and every independent owner gets a yellow alert the same hour. Most hand-written fediverse projects have no fleet-wide alert at all. We would rather be the project that over-warns.
Yes. Fixes are generated fast, tested against a private lab of Pixelfed, Mastodon and GoToSocial servers, and shipped as signed releases. When it’s critical, it goes out by hand. This is stewarded software, not a passenger seat.
Yes. The provenance is published on THE RECKONING down to the line count. The failures are published on DING DONG BELL. Nothing about how this was made is hidden, because hiding it would be the actual risk.
Don’t trust my typing — judge the artifact. The code is AI-produced, which is exactly why I don’t just trust it. That’s what the audits, the pen tests, and the disclosure policy are for.
And the part that answers the fear underneath the question — could it turn on the network? — is the first rule on this page. SnapSmack cannot remotely control anybody’s site. Not Sean, not the network, not a compromised central server. A warning network, not a botnet. The lack of a kill switch isn’t a missing feature. It’s the feature.
Receipts