aboutsummaryrefslogtreecommitdiffstats
path: root/src/remake/catchup.rs
Commit message (Collapse)AuthorAgeFilesLines
* remake: earlier epochs' metadata read as the snapshot built ittv3 days1-3/+10
| | | | | | | | | | | | | | A snapshot leaving out earlier epochs' metadata (`snapshot::left_out`) and a rejoining node (`catchup::prepare`) read it from the document as it stands. It is never writable through the store, and under a policy the rules take a change to it only from an epoch's first; but with no policy, screening judges only an epoch's root, so a member's own change could rewrite or remove an entry: a replay window narrowed or widened, a translation or a clock changed, a strict remake's entry gone. Now both read it at the epoch's snapshot change (`snapshot::as_built`), as `verify_document` reads the epoch's own: a snapshot from its base's epoch's, a rejoining node from the target's. Every earlier entry is a copy in that change, so what was written there since doesn't count. The first epoch follows none and has none.
* remake: leave out earlier epochs' metadata past the replay windowtv3 days1-1/+5
| | | | | | | | | | | | | | | | | | | | | 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".
* remake: a strict remake of a strict swarm isn't followedtv3 days1-0/+16
| | | | | | | | | | | | | | | Review 3, R3: 1186 kept honest nodes from proposing or voting for a strict remake of a swarm strict already, but a majority of members, each with keys of its own, could still commit one, and switch and catchup followed it without asking what kind of remake made the epoch: the registry, policy and bans of a strict swarm changing by a member majority, the honest minority following. A node now refuses to switch to such an epoch (its document's policy strict, the remake's kind strict), and catchup refuses to rejoin one whose chain of epochs holds a strict remake after the swarm was strict (as the old document is, or once a remake since made it so). access.md says so.
* rules: a carried remake record taken from the coordinator its snapshot namestv3 days1-0/+1
| | | | | | | | | | | | | | | | | Review finding 7, second part: a record carried into a new epoch whole (proposal and decision in one change) was taken from any member, for any remake ID. A member could write a forged record, decision included, for a fresh ID in a single change. The snapshot's epoch metadata now names the remake's coordinator, as the quorum built it. The carried-record exception holds only in a later epoch, only for the remake that made it, and only from the coordinator its snapshot names, where there is no record yet. Wire version 43: the snapshot, and so the epoch ID, changes. The review suggested carrying the record inside the snapshot instead. The snapshot can't hold the decision, which names the snapshot's own hash. So the snapshot vouches for who may carry the record instead.
* remake: replays judged before they go intv3 days1-0/+2
| | | | | | | | | | | | | | | 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).
* remake: replays keep their writerstv4 days1-0/+3
| | | | | | | | 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).
* document: allow writes during rejointv10 days1-178/+210
|
* LWW everywhere, mostlytv10 days1-9/+25
|
* remake: copy stale view when writes stoptv10 days1-5/+6
| | | | This ensures that stale reads show every write that was answered.
* remake: introduce follow-the-majority ruletv10 days1-27/+139
|
* document: reject writes during rejointv10 days1-17/+35
|
* use Automerge as Document instead of AutoCommittv11 days1-17/+15
| | | | This allows a lot of operations to drop mut.
* tests write through document::testing helperstv11 days1-6/+6
|
* make clippy happy againtv2026-10-261-8/+11
|
* wrap unix timestamps in newtypetv2026-10-261-7/+22
|
* add clock moduletv2026-10-251-9/+25
| | | | | The Clock module is the system clock that every unix timestamp new goes through. It comes with an offset that only tests can set.
* only keep list of actor IDs within one epoch (fixup)tv2026-10-251-0/+2
|
* nodes keep list of every actor ID they've usedtv2026-10-251-9/+23
|
* corroberate newer epochstv2026-10-241-11/+53
|
* follow and download from ready members onlytv2026-10-241-1/+3
|
* put remake content into blobstv2026-10-241-1/+1
|
* add chunked download and use it during rejointv2026-10-241-2/+47
|
* rename cluster to swarm everywhere!tv2026-10-211-14/+14
|
* turn compaction into a kind of remaketv2026-10-211-22/+49
|
* rename compaction to remaketv2026-10-211-0/+506