| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
An import uploaded as `application/octet-stream` takes `rules`, `baseHeads`, `settle`
and `switchDelay` in the query, but not the retentions: for those the document had to
go base64-encoded in the JSON form. Now `replayWindow` and `archiveRetention` go in the
query too, as JSON like the rules (`{"epochs":1,"age":"7d"}`, as in the body).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Every snapshot carried the metadata of all earlier epochs (`_continuum/epochs`)
forward, so it grew by an entry, a clock per actor among it, with every remake. Only a
rejoining node reads an earlier entry: a node on epoch P reads P+1's (its clock, when
it was proposed, its replay window) and every one up to the swarm's epoch (kind,
translation, whether it was strict). It replays only while P+1's replay window covers
it; beyond, its writes are quarantined whatever the entries say.
So a snapshot now leaves out the generations older than the oldest whose replay window
still covers a node on the epoch before it (`snapshot::left_out`), judged by the
remake's `proposedAt`: the same on every node, and earlier than any rejoining node's
clock, so nothing a node can still replay through goes. Metadata that doesn't read
stays, with all after it.
A strict remake's metadata stays for good: by it a rejoining node, however far behind,
tells a strict remake of a swarm strict already (`catchup::prepare`, which reads the
generations it finds). There is at most one, short of such a remake. No new key and no
change to the rejoin: a node beyond the window that finds some entries and not others
quarantines with "cannot translate" rather than "outside the replay window".
|
| |
|
|
|
|
| |
Review 3: since 1184 a proposal is written as the user who asks, so
under a policy the node doesn't know it answers 409 like every user
write. remakes.md says so.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Review 2, N3: 1150 let any member write an abort decision once a remake
had expired a grace period ago, judged by the change's own time, the
writer's word. A member could race the coordinator's legitimate commit
with an abort dated as it liked; both taken, Automerge shows
one, and nodes that acted on the commit split from those that didn't.
The two writers of such aborts are operator requests whose endpoints
already need write on _continuum/remakes: aborting an expired remake
(DELETE /admin/remakes/{id}) and superseding one (POST
/admin/remakes?force=supersede). Both now commit as the user who asks
(the proposal and its vote with them, for a supersede), which the rules
take as one who may write the decision. The clause judging an abort by
its time goes, and with it the time the rules carried. An expired
remake is still aborted through any member, by an operator.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under a policy, a remake's decision was taken from its coordinator only.
A node aborting an expired remake whose coordinator is gone
(DELETE /admin/remakes, after abortableAt) was refused by its own
judgement (403), so such a remake could never be decided.
The decision is now also taken from a user who may write it (the
protocol writers), and an abort from any member once the remake expired
a grace period ago (abortableAt, by the coordinator's grace period in
the proposal). The rules have no clock of their own, so that is judged
by the time the change says it was made: the writer's word, so a member
could abort a remake early, as it could ask its coordinator to, but
never commit one. Before then, an abort stays a request the coordinator
applies.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A switching or rejoining node replays late writes as fresh changes
naming each write's user, and nothing judged them before they left: a
replay every node would refuse (a revoked capability, a second
envelope at a signed path, readers changed) was refused everywhere,
and with it everything the node wrote after it.
Under a policy, replay_newest now judges each group it commits as
every node will (rules::judge_held, in the new epoch); one they would
refuse is taken back (forked at the heads before it, same actor) and
its paths quarantined with the reason. replay_newest takes the epoch.
Review finding 3 (remake replays).
|
| |
|
|
|
|
|
|
|
|
| |
POST /admin/quarantine/{id}/replay needs write on _continuum, which
never covers user data, and replayed every path of the entry as the
user who asked: every node refused the user data in it. It now
replays only the paths the user may write and keeps the rest in the
entry (left), for one who may; 403 if the user may write none.
Review finding 3 (quarantine replays).
|
| |
|
|
|
|
|
|
| |
A remake's replay writes each value as the user who wrote it,
splitting where several users wrote under a path, so replays are
judged as the original writes.
Auth plan M6 (remakes, 2.4).
|
| |
|
|
|
|
|
| |
Forget records and released quarantines name the user who made them,
so they are judged by its capabilities.
Auth plan M6.
|
| | |
|
| |
|
