Publish gates before permanence
Publish gates before permanence are the checks that run while a MediaWiki save or a Git push is still local, so permanent and content-addressed publishes almost never need an after-the-fact erase story. The live wiki can delete a revision. A CID other people already pinned, or an Arweave write already mirrored, can remain fetchable. Gates exist to make that bad case rare by design. This page maps practical pre-save and pre-push checks for secrets, personally identifiable information (PII), spam, and malware. It is informational and concrete. It is not a claim of perfect safety, not a vendor pitch, and not a full install manual.
The integrated project shape for wiring these checks together is described in Pre-publish checks for MediaWiki and Git under Project proposals.
Airline-safety thinking for publishes
Commercial aviation treats accidents as events that should be rare because many independent controls sit between an ordinary flight and a catastrophe. Checklists, redundant instruments, training, and maintenance exist so that one tired mistake does not equal a headline. Permanent publishing needs a similar attitude. The goal is not a speech about caution. The goal is a sequence of gates that catch the worst classes of mistake before bytes leave the machine.
A publish that can be globally mirrored is closer to a takeoff than to a private draft. Once the snapshot is public under a content identifier, coordination to erase every copy is unreliable. Design so that secrets, doxxing dumps, malware links, and bulk spam almost never reach that line. Accept that some failures will still happen, measure them, and improve the gates. Do not plan on silent global deletion as the primary safety system.
Why the bad case should be rare
MediaWiki revision history and Git commit history make mistakes recoverable on a single host when operators act quickly. Content-addressed wiki exports and long-retention networks change the stakes. A bad paste can outlive the editor who noticed too late. See Content-addressed wikis and Local-first wiki and Git mirrors for how mirrors and permanence fit the publishing path.
Rarity by design means layered detection while undo is still cheap. A laptop commit that never pushed is easy to amend. A wiki edit that never saved is easy to rewrite. A mirrored CID is not. Gates belong at the network boundary: browser and server checks on save, pre-commit and pre-push on Git, and a final review before a scheduled export to IPFS or Arweave.
Gate map: what each layer catches
Secrets
Accidental secrets include API keys, private keys, tokens, .env fragments, and similar credentials pasted into a page or committed into a repository. Pattern and entropy scanners catch many of these shapes. On the Git side, Gitleaks-class open source scanners can run on staged changes and again on the range about to leave the machine. On the wiki side, server-side regexes and similar rules can block or warn on high-confidence key material in the diff.
What this gate catches: credentials that would grant access if published. What it misses: novel secret formats, secrets split across fields, and intentional publication of public test keys that look private. Allowlists must stay small and reviewed. Scan logs must redact matches so the safety system does not become a second leak.
Personally identifiable information
PII gates look for names tied to private contact data, government identifiers, and other personal details that should not go public without a clear process. Local and open token-classification models, paired with deterministic validators, can warn in the browser before text uploads. Server-side checks should still run, because client scripts are bypassable.
What this gate catches: common identifier patterns and labeled PII tokens in the edit. What it misses: sensitive facts that use no standard identifier shape, and context that only a human recognizes as private. Educational wikis that discuss privacy or security need policies that distinguish analysis from dumping private data about real people.
Spam
Spam gates target bulk promotional text, repeated link farms, and low-value floods that drown real edits. MediaWiki AbuseFilter can warn, throttle, tag, or disallow edits that match operator-written conditions. SpamBlacklist-style tools block saves that add external links matching configured host patterns. Trainable open classifiers in the SetFit or sentence-transformer family can add a spam hint layer behind rules when a team labels its own examples.
What this gate catches: repetitive junk and known bad link patterns. What it misses: clever one-off spam, new domains, and good faith edits that trip crude rules. Over-blocking technical discussion harms a wiki. Operators should measure false positives on their own corpus and keep a human appeals path.
Malware and hostile links
Malware and scam URL gates compare newly added links against reputation feeds and blocklists, including community malware URL intelligence such as URLhaus-style feeds consumed by downstream filters. AbuseFilter and blocked-external-domain features can enforce whole-domain rules with a clearer audit trail than giant opaque regex lists alone.
What this gate catches: known-bad hosts and many phishing or malware distribution URLs already observed in the wild. What it misses: brand-new malicious domains, compromised good domains, and links that are safe to quote for analysis but unsafe to promote. Site policy should say when quoting a bad URL for documentation is allowed.
Where local and open tools fit
AbuseFilter is the mature MediaWiki rule engine for edit-time conditions and actions. It is a rules system, not full language understanding. SpamBlacklist and related domain blocks cover outbound links. Together they are the server enforcement spine for the wiki path.
Gitleaks-class scanners are the Git spine for secrets. Run them at pre-commit, pre-push, and again in continuous integration. CI alone is not enough for unprotected branches that push straight to a public remote.
Local and open models act as classifiers and PII labelers when a team refuses to send every draft to a hosted moderator. Small models can warn in the browser. Larger models can score text on a server the organization controls. Hosted yes-or-no decision APIs exist for teams that accept that dependency. Fully self-hosted gates prefer open weights and local hardware. In every case, models produce false positives and false negatives. They need domain examples and human review for borderline scores.
URL reputation feeds lag and can false-positive. Keep an override path with logging. Re-check feed quality on a schedule. Treat named tools as building blocks whose versions and licenses change, not as permanent endorsements.
Browser courtesy, server enforcement, export freeze
A practical MediaWiki path uses three moments. First, a browser warning when the editor clicks save: scan the diff for secrets and PII, flag suspicious links, and ask for confirmation or redaction. Second, a server check that cannot be turned off by disabling scripts: AbuseFilter, link lists, secret patterns, optional model scores. Third, an export freeze before IPFS or Arweave publish: re-scan the snapshot, require a signed manifest, and record who approved the release.
A practical Git path mirrors that shape: pre-commit for fast feedback, pre-push for the network boundary, CI for pull requests, and a release job that refuses to upload a tree that still fails secret scanning.
Limits that honest operators name
Automated gates will wrongly block good edits and miss bad ones. Logs can themselves leak if they store full secrets. Attackers adapt. Filters cannot replace law, trust and safety staff, or clear site rules. Permanent storage can outrun deletion even when the live wiki is clean. Educational discussion of malware and security must remain possible under policy, or the wiki becomes less useful precisely where it should teach.
These limits are why layered gates beat a single magic model. Rules and feeds first, local classifiers second, humans for borderline cases, hard blocks for high-confidence secrets and known-bad lists.
Conclusion
Publish gates before permanence treat a durable MediaWiki or Git release like a takeoff: many checks while undo is still local, so erase stories stay rare. Secrets, PII, spam, and malware each need detectors that match their shape. AbuseFilter, Gitleaks-class scanners, URL reputation, and local or open classifiers are concrete pieces. Browser warnings help authors. Server and hook enforcement stop bypasses. Export-time re-scans protect mirrors. The proposal page Pre-publish checks for MediaWiki and Git frames the combined pipeline. Operators who wire those gates, measure errors, and keep private data off public networks get permanence without planning on global deletion as the safety net.