Threats

The archive is not an election. A few percent of junk in a fully published corpus does not poison it; anyone using the corpus filters it, as they do any corpus. What would ruin it is undetectable coordination, silent alteration, or an operator who cannot be checked. This page lists what can go wrong, what is done, what is accepted, and what each friction actually costs, so that no one has to guess.

The table

Threat	What is done	Status
Bulk automated submission	Typing figures published beside every entry; first-submission friction below; daily counts in the public log	Made visible, made tedious; not prevented
Queuing or batching many messages from one set	One message at a time; the next key inert until it unlocks, 7 days later	Defended
Key harvesting from public pages	Keys shown once, never published, single-use, stored only as hashes	Defended
Silent manipulation of the record by the operator	Nothing edited; removal only by the published procedure with a tombstone; hashes on every entry; chained, write-once snapshots deposited outside the operator's control; a public verifier	Made checkable
Silent change of the rules	Every one of the archive's own pages carries a revision number and date; past revisions stay at dated addresses; the terms revision in force is recorded on every entry	Made checkable
Impersonation of a public figure	No name field, so the archive asserts no identity; a name inside a message is only the writer's own words	Removed by design
Many independent first submissions from one actor	The frictions below; public timestamps; the 7-day wait, which every fake set must sit out twice to look complete	Accepted, made deliberate
A coordinated campaign of real people	Transparency: timestamps, the corpus, and the daily counts make a burst visible; no per-entry coordination field, by decision	Accepted, made visible
A distressed writer who thinks someone reads the queue	The terms say plainly that no one does and that there is no crisis response	Stated, not solved
A message that names or endangers a private person	The review screen asks the writer to take names out before publishing; the terms give the named person the remedy the law provides, and nothing more	Accepted, with a remedy
Loss of the operator	The continuity page, the second keyholder, the deposits, the orphan clause	Planned; see that page for what is true today
Loss of the host or the registrar	Plain files rebuildable from any snapshot with the public code; DNS-only records that can be pointed anywhere; a compulsion category in the terms for a host that would otherwise take the whole site	Accepted, made recoverable

The frictions, with numbers

Every friction applies to a first submission only. A writer returning with a key pays none of them.

The proof of work asks the browser to find a counter such that the SHA-256 of a server-issued nonce and the counter begins with 17 zero bits. That is about 131,072 hashes on average: a few seconds in the browser's JavaScript on an ordinary phone, and milliseconds in native code on any machine. It stops nothing that is written to get past it. It exists so that the obvious script is not zero-cost and so that the nonce, which is single-use and expires after 15 minutes, ties each attempt to a moment. The difficulty is fixed and published here; it does not rise under load, because the trigger for raising it cannot tell an attack from a news article, and it would harden the door exactly when coverage brings sincere strangers on old phones.

The nonce endpoint itself allows 30 requests per hour from one network address, counted against a salted hash of the address that is kept for one hour and then deleted.

First submissions are limited to 6 per hour and 20 per day from one network address, counted against a salted hash kept for one day. The limits are loose on purpose: carrier-grade NAT, universities, and offices put many real people behind one address, and a limit tight enough to stop one determined person would stop a classroom.

The writing page keeps a count in the browser's own storage of how many sets have been started from it, and closes the box to new sets at 3. Anyone can clear it. It makes the obvious path finite and the workaround a deliberate act.

Taken together, these do not make twenty sets cost real time. A person with a script and twenty addresses can open twenty sets in an afternoon, and can come back a week later, twice, to complete them. What the frictions do is make that a series of deliberate acts, each of which leaves a mark: in the typing figures, which a script must forge; in the daily counts in the log, where a burst shows; and in the timestamps, which no one can backdate. The archive's position is that visible, deliberate manipulation is a fact about the manipulator that the corpus records, and that the price of stopping it would be a gate that real people fail.

Three things to be plain about

One operator, unaccountable to any institution, holds the keys. The checks on that person are external and public: the hashes, the chained snapshots deposited with custodians the operator does not control, the verifier anyone can run, the revision history of every page, the public log of every demand, and the standing rule that the operator never quotes or characterizes an entry anywhere. If the operator breaks the rules, the evidence is in the open, which is the most an unaccountable person can offer.

The frictions make the workaround deliberate; they do not stop a funded actor. Nothing on this page would survive a well-resourced campaign, and the archive does not claim otherwise. It claims that such a campaign would be visible in the record it leaves.

The score can be forged, which is why it never gates. Published attacks show that keystroke timing can be synthesized. The composition score is a published summary that a determined actor can fake, and a sincere writer on an unusual device can fail. It decides nothing. Its use is that forging it is work, and that the figures beside it let anyone form their own view.

Bypasses

Anyone who finds a way around any of this is asked to say so at hello@messagestowhatcomesnext.org. Every reported bypass is published in the log with the date received and what, if anything, was changed, and no limit is ever tightened during a campaign without the change being published first.

Revision 2, effective September 25, 2026. Earlier: revision 1 (September 25, 2026).