remake: turning a running swarm strict, keeping what an operator signed

Until a swarm is strict, the user a change names is its node's word, so
any member could have planted registry entries, policy, bans or
user-signed values as any user, plain or signed by a key it put there
itself; writing the strict policy trusted all of it as it was.

A remake of a new kind, `strict`, turns a swarm strict instead:

* Its content is a manifest (access::strict): the swarm, the strict
  policy, and each value kept at the places values are signed, by the
  SHA-256 of its JSON, signed by an operator (ssh-keygen -Y sign -n
  continuum-strict).
* Every node builds the next epoch as compaction does, keeping at the
  signed places only the values the manifest names, as they were at
  the base, and writing its policy (RemakeKind::protocol, the one kind
  that changes protocol data). Writes after the base reach the new
  epoch only by replays, judged by the strict policy.
* A node votes for one only with its manifest signed by one of
  --strict-keys, keys given out of the document; without any, for none
  (logged once, `Not voting for a strict remake`), unless
  --follow-strict-remakes. A coordinator proposes only what it would
  vote for (403). Once a majority commits one, every node switches, as
  with any remake: refusing to switch would only cut a node off.
* GET /admin/strict-manifest gives the manifest keeping everything held
  now, the values for review and the heads they are at;
  continuum-signed strict shows them, signs once confirmed and proposes
  at those heads.

The sim a_swarm_turning_strict_through_a_remake: a member plants a
registry entry as a manager; the operator's manifest leaves it out; a
and b, given the key, commit; c, without, follows; the entry is gone
and the policy strict everywhere.

1 files changed, 35 insertions, 2 deletions

diff --git a/docs/access.md b/docs/access.md
index 5941bdb..9bd99cc 100644
--- a/docs/access.md
+++ b/docs/access.md
@@ -380,8 +380,11 @@ API changes nothing (`409`). Values there before the policy stay as they are unt
 replaced: a registry whose entries hold the users' keys turns strict as it is. As it is
 means trusted as it is: whatever entries, policy and bans it holds then count, plain
 values and envelopes alike, checked or not, whoever wrote them before (under a policy
-that isn't strict, a member may write as any user). Look them over before turning
-strict (`continuum-signed verify` on each entry). A value there that isn't an envelope
+that isn't strict, a member may write as any user). So a swarm is best strict from its
+start (`--bootstrap-keys`, A new swarm, above); one already running turns strict
+through a remake (Turning a swarm strict, below), which keeps only what an operator
+looked over. Writing the strict policy into it directly trusts it as it is: look it
+over first (`continuum-signed verify` on each entry). A value there that isn't an envelope
 starts its chain anew: any envelope its user once signed for that path replacing
 nothing (`prev` empty) can be put there again. Without the policy, signed values may
 be written all the same, and plain ones too.
@@ -397,6 +400,36 @@ replacing or deleting what holds one (a map made where there is none yet is fine
 a member writing to its document directly gets nothing there past the others: the
 registry, the policy and the bans change only as a user who may change them signed.
 
+### Turning a swarm strict
+
+A running swarm turns strict through a remake of its own kind, `strict`: compaction
+that keeps, at the places values are signed (the registry, `_continuum/access`, the
+bans, the paths listed in `userSigned`), only the values an operator looked over and
+signed, and sets the strict policy. What was written after its base reaches the new
+epoch only by replays, which every node judges by the strict policy: a value planted
+before, plain or signed by a key its planter put there itself, is gone unless the
+operator kept it.
+
+Every node is given the keys whose signature it takes on such a remake, out of the
+document (`--strict-keys`, `authorized_keys` lines): one an operator holds. A node
+votes for a strict remake only with its manifest signed by one of them; without any,
+it votes for none (logged, `Not voting for a strict remake`), unless
+`--follow-strict-remakes`. Once a majority commits one, every node switches, as with
+any remake.
+
+```sh
+continuum-signed strict
+```
+
+shows the values it would keep (`GET /admin/strict-manifest`: every value at a signed
+place now, by its digest, and the policy with `"values": "signed"`), signs the
+manifest once confirmed (`ssh-keygen -Y sign -n continuum-strict`, with a key of
+`--strict-keys`), and proposes the remake at the heads it was made at (`{"kind":
+"strict", "spec": {"manifest": "<its line>\n<its signature>"}, "baseHeads": […]}`). To
+keep less, take the manifest from `GET /admin/strict-manifest`, leave out of its `keep`
+what should go, and sign that instead. Reading it needs reading `_continuum`, proposing
+writing `_continuum/remakes`.
+
 ## Values sealed for their readers
 
 Anyone may read the whole document: every member holds it. A value only some may read