| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
| |
Review 2, N7, measured first: a node whose document has no policy (a
joiner's empty one) applies what it receives unjudged. Screening it too
would cost finding every change's paths and judging it. bench_screening
takes 1 000, 10 000 and 100 000 changes into an empty document, as one
delta brings them: unjudged, as Automerge applies them, against
screened (access::screen::apply), with no policy in them (each passes,
read at its dependencies, after its paths were found) and with the
policy their first change wrote (each judged by the rules).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Review 2, N2: nothing checked that a strict remake's base wasn't strict
already. In a strict swarm the registry, the policy and the bans change
only as a user who may change them signs; a strict remake committed by
a majority of members, each with keys of its own, could drop any of
them (unban, remove managers, empty userSigned and the sealed
declarations), and the honest minority would follow.
A node now takes a strict remake (proposing or voting) only in a swarm
not strict yet: turning strict is done once, by a remake; after it, by
signatures.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Review 2, N8: a node with one neighbour (a swarm of two, a leaf) never
hears a second member name the change: its big drop was held for good,
an error logged at every REFUSALS. It now waits only where it has
another neighbour than the one telling it; with one, one word is all
there is.
access.md also says what the wait is: it guards against one peer, not
two members saying the same (any node with the swarm key registers),
and never makes a node drop what its own rules take.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Review 2, N1: a strict manifest wasn't bound to its base. Any member
could propose an old, legitimately signed one again at the current
heads; nodes would verify it and vote, and every value at a signed
place changed or added since (a ban, a new user, a rotated key, a
changed userSigned or sealed declaration) would be deleted, nothing
after the base being left to replay.
The manifest now names the epoch and the heads it was made at, and a
node takes it (proposing or voting) only for a remake of that epoch
with exactly that base. GET /admin/strict-manifest makes it so;
continuum-signed strict proposes at those heads already.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Review 2, N12: a strict remake kept only the values at the signed
places its manifest names, and copied what holds them as it was. A
member that replaced _continuum/users by a scalar before the turn left
the strict epoch without a registry, where any member may do anything.
The holders of the registry, `_continuum/access` and the bans are now
made anew as maps, with only what the manifest keeps copied into them;
and a manifest keeping no user is refused (at proposal, vote and build
alike), as a strict swarm without one would trust every member.
|
| |
|
|
|
|
|
|
|
| |
Review 2, N10: the judgement before a change leaves (1140) and a
replay's (1141) skipped changes when the document *with* the change had
no policy it enforces. A write removing the policy, or setting one the
node doesn't know, then left unjudged, while receivers judge it at its
dependencies, where the policy was enforced. Both now read the policy
at the heads before the change, as receivers do.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Review 2, N6: finding 2's class survived for two reads the frontier
didn't cover: whether a map a change makes is there (maps made on the
way, 1137; holders made where none, 1147, for any path), and
_continuum/votes, which `relevant` didn't list. A crafted pair, the
second making a map the first made, was taken by nodes receiving both
in one batch (judged at the frontier, where the map isn't yet) and
refused by nodes receiving them apart.
The screen now keeps the paths the accepted, not applied yet, touch;
a change making a map at one of them is judged after they go in. Votes
join what `relevant` lists. A crafted pair needs hand-made changes,
which the tests don't build.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Review 2, N5: under a strict policy a user's signed PUT of its own
entry, keys changed (continuum-signed key-add), passed the API and
envelope::check's own_keys_only, and was then refused by the rules'
path check: _continuum/users/<name> wanted write on the registry, so the
node judged it as every node would and answered 403. 1168 worked only
without strict.
Under a strict policy the rules now take a write of a user's own entry
from that user, leaving what it may be to signed_values, which runs
envelope::check: an envelope by the user, with only its keys changed,
one left at least. Strict only: under another policy the entry isn't an
envelope, and the user would rewrite its own capabilities.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Review 2, N4: replay_newest names the node the document's author once,
before its first group. Taking a refused group back forks the document
at the heads before it, and Automerge's fork has no author; when the
refused group was the actor's first change, the next one was committed
as seq 1 without the footer naming the node, refused as "it names no
node", taken back too, and so on: the whole replay in the quarantine
with a misleading reason.
The fork now names the node its author again. Test: the first group
refused (a capability revoked in the new epoch), the next replayed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A strict remake takes a majority of members whose --strict-keys take
its manifest's signer: no node votes for one without, so
--follow-strict-remakes (1173) goes. A node that doesn't vote still
switches once the others commit, as with any remake.
So that an operator can tell why one fails: a strict remake aborted
for want of a majority (the voting period over, or a majority out of
reach) says in its reason (GET /admin/remakes/{id}, and the
coordinator's log) which members didn't vote, and that a member votes
for one only with its manifest signed by a key of its --strict-keys.
Each of those logs why itself (`Not voting for a strict remake`).
The sim a_strict_remake_too_few_take: only a takes the manifest; the
remake aborts, naming b and c.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The user's name, top right, opens a menu:
* "credentials…": the user's keys (GET /auth/keys), one added with its
.pub line or removed but the last (/auth/keys/{id}); under a strict
policy, how to sign them anew (continuum-signed key-add, key-remove);
and where its password is: each node's --htpasswd, its operator's.
* "log out": this browser's session ends. Where the page got in by
what it can't end (the browser's password, the proxy's), it is greyed
(aria-disabled, not disabled, so a click still lands), its tooltip
saying how to log out, and a click says so in a dialog.
The log out button and the text beside the name from 1165 go into it.
Checked in Chromium against stubbed endpoints: the menu, both log out
cases, the credentials dialog, no errors, nothing the content policy
refuses.
|
| |
|
|
|
|
|
|
| |
A user managing its own keys (1168) could remove the last, and then
neither sign nor log in by key. It can't now: DELETE /auth/keys/{id}
of the last answers 409, the rules take a user's change of its own keys
only with one left after it, and under a strict policy its own entry
signed only with one key at least. One who may manage users still may.
|
| |
|
|
|
|
|
|
|
| |
What is meant for browsers logs in on its page (/login), with the
passwords of --htpasswd; basic authentication's challenge stays for the
API, so curl -u keeps working. 1164 kept it from a page's own requests;
now nothing under /admin/dashboard is challenged either, whatever the
request: a browser opening the page without a user is sent to /login,
anything else answered 401 without a challenge.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A node told (REFUSALS) that it holds a change the swarm's rules refuse,
and whose own rules refuse it too, dropped it and everything built on
it on one peer's word, however much that was; its own writes among them
went to the quarantine, the others' nowhere.
* A drop taking more than 100 changes, or more than ten and a tenth of
the document, now
waits until a second member names the same change: the node's rules
and one peer's word could both be off. Logged as an error, counted in
/admin/stats (sync.dropsHeld).
* The others' changes dropped are listed with the refused (GET
/admin/refused, "taken unjudged, dropped"), for operators to see.
The cheap half of asking the others (future-work.md, Telling a
malicious change from a wrong policy).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Only a user who may manage users could change a user's keys: a user
couldn't add a new laptop's key, or remove a lost one.
A user now manages its own keys, whatever else it may do:
* GET /auth/keys: its keys, its entry, and the envelope holding it
under a strict policy (`signed`), to sign against.
* PUT /auth/keys/{id} with an authorized_keys line, DELETE
/auth/keys/{id}: one change, as the user. The rules take a write of
_continuum/users/<name>/keys/… from the user it names.
* Under a strict policy, the user signs its entry with only its keys
changed, with a key it holds already (envelope::check takes that from
the user itself), PUT to its own entry even without write on the
registry; continuum-signed key-add and key-remove do so.
|
| |
|
|
|
| |
Since judge_held moved to access::rules (1140), swarm::refusals uses
ReadDoc no more; clippy warned.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Review 6: a node remembers the challenges used until they expire, 10 000
at most, and refused every login by key once full. One user holding a
key could make 10 000 logins within five minutes and keep everyone else
out.
A user may now log in by key at most --key-logins-per-user times (100)
on a node within a challenge's lifetime, past which that user waits and
others don't; the 10 000 stay as the cap for all users together. The
lifetime, five minutes until now, is --challenge-lifetime.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The dashboard had no way to log out; only the login page did.
It now shows the user beside the connection, and "log out" where the
page got in by its session: that ends this browser's session (DELETE
/auth/session), other sessions of the user going on, and opens the
login page. Where it got in by what it can't end, the browser's
password or the proxy's, it says so instead (the token answer now
names `login`, how the user proved it). After logging out, a page
still let in by the browser's password says so too.
A list of a user's sessions, to end one by one, is in future-work.md.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Opening a dashboard through its login page showed a 401 on /auth/login
and the browser's password prompt. The page asked for its token by the
browser's password first (POST /auth/login), with none to send, and the
401 carried a Basic challenge, which a browser answers with its prompt.
The page now asks by its session first (POST /auth/session), then by
the browser's password or the proxy's. And a 401 to a page's own
requests (Sec-Fetch-Dest: empty: fetch, EventSource) carries no
challenge: a page has its login of its own. Navigations and clients
without the header (curl) are still challenged.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Simulations backing what the review's fixes changed, beyond their unit
tests:
* a_change_forged_under_another_members_actor (1145): a change made
under b's actor at the seq of b's last change, judged by a: refused
as forged, b not refused as a whole, b's next write taken.
* an_expired_remake_aborted_by_any_member (1150): under the policy, a
coordinator gone before it decides; b aborts its remake once it
expired a grace period ago, c takes the abort, nothing refused.
* a_strict_swarm (1155): a value alice signed for another swarm,
replacing the one there, is refused as such.
|
| |
|
|
|
|
|
|
|
|
|
| |
A change waiting for a dependency that hadn't come stayed waiting when
another of its dependencies was refused meanwhile, until the bound
pushed it out. Changes building on one refused before were refused one
generation per batch.
Building on a refused change is now followed through at once, before
judging and again after (refuse_building): whatever waits on a change
refused in the batch, or on one of those, is refused then and there.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Review section 7: Automerge takes the changes judged in a batch all or
none, so one it won't take (a fork of an actor's changes, under a
policy without signatures) fails the whole batch, and every batch
carrying it. The log said who sent the message (`Failed to process sync
message`, `Delta download failed`, with the peer) but not what failed.
The error now names the changes it was given, the first eight, each
with its seq and the node it says made it, so whoever sends the
offending one shows in the log beside what it sent.
|
| |
|
|
|
|
|
|
|
|
|
| |
Review finding 12, browsers: the session cookie had no Secure flag.
Behind a TLS proxy, the token it carries went over plain HTTP if
someone typed http://.
POST /auth/session now sets Secure when the request came over TLS, as
the proxy says (X-Forwarded-Proto, or Forwarded's proto, of the first
hop). A client saying so itself only keeps its own cookie off plain
HTTP. operations.md's nginx example sets the header.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Review finding 12, browsers: the dashboard holds a bearer token in
memory and edits the document, but had no content security policy and
could be framed by any page of the same site (another port on the same
host, anything sharing a domain behind a proxy), acting with its user's
token.
The dashboard and the login page now come with a policy that runs only
their own inline script (by its hash, computed when first served),
loads nothing from elsewhere, and lets no page frame them
(frame-ancestors 'none', X-Frame-Options DENY). Fetches stay open to
any origin, as the members' dashboards are wherever the member list
says.
The browser check (check.js) loads the page from a file, without the
header, so the policy wants one look in a browser.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Review 3.1, part of finding 12: a signed value's payload bound path,
user, time and prev, but not the swarm. A user with the same name and
key in two swarms could have an envelope replayed from one into the
other, wherever the path holds no envelope yet (prev "").
The payload now names the swarm (`swarm`), and a node takes an envelope
only for its own. /auth/whoami says the swarm, and continuum-signed and
the example in api.md sign it. Wire version 44: nodes before this
refuse such envelopes, and those after refuse the old ones.
|
| |
|
|
|
|
|
|
|
| |
Review finding 11: token::verify checked only that the issuer is a
member, and a ban leaves the member entry. A compromised node's tokens
stayed valid after it was banned, until it was forgotten too.
A token issued by a banned node is now refused (BannedIssuer), as soon
as the ban reaches the node judging it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Review finding 9: once 4096 signatures waited for their changes, new
ones were dropped, and the waiting changes were cut at 10 000 keeping
the oldest. A member could send junk once (signatures of changes that
never come, changes no signature will vouch for) and fill both for
good. Every honest signature arriving before its change was then lost,
so under signatures required its changes waited for the actor's next
signature: a stall for quiet actors.
Both now keep the newest: the oldest go. A share per sender, so a member
sending junk without pause can't push out what others sent either, is
in future-work.md.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Review finding 8, second part: opening another member's dashboard
handed it a token reading everything (READ_ALL). A member writes its
own dashboard URL, so a malicious one received a read-everything token
under the operator's identity: /admin/config, /admin/changes,
/admin/log and the rest, on every node the user reaches.
The token handed over now reads the member list only (READ_MEMBERS, as
sent to subscribed nodes), which is enough to draw the map; the user
logs in at the other dashboard to see more. With 1151 it lasts five
minutes and isn't refreshed past them.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Review finding 8, first part: a refreshed token's lifetime came from
the refresh request, and it kept the session's end. So the five-minute
read-all token a dashboard hands to another member's refreshed into a
12-hour one, renewable for seven days.
A token asked to live less (`lifetime`, at login or refresh) now ends
its session with it: nobody refreshes it past its end, its holder
included, and a session begun from it (POST /auth/session) ends then
too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Review finding 7, first part: the protocol-map rules looked at paths,
not actions. Any member could delete _continuum/members, /votes or
/remakes whole, or rewrite another remake's proposal (its coordinator)
and then write its decision.
What holds the members' entries, votes and remake records, and a
remake's record itself, are now made by a member only where there is
none; a proposal is written only where there is none. Replacing or
removing any of them is left to a user who may write there (the
protocol writers). An abort asked for stays any member's.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Review 2.2: swap_document forgot every signature. After dropping
changes taken unjudged (or a rejoin into the same epoch), the node
could vouch for none of the changes it kept: under signatures required,
those building on an actor waited for that actor's next signature, and
for an actor that stopped writing, forever.
Signatures::kept_for keeps the signatures of the changes the new
document holds, checks each actor's latest again, and keeps those
waiting for their changes. This node's replayed changes are signed at
once, as before.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Review finding 5: vouching by (actor, seq) isn't bound to a hash. A
member can make a change under another member's actor at a seq that
member's signature covers. The change is then taken as vouched, and if
it breaks a rule, the honest member is refused as a whole and logged as
the one whose own change broke the rules.
A signature now vouches for its change and the changes of its actor it
builds on: in the document, as before; among received changes, those
it reaches through the batch's dependencies. A received change under an
actor at a seq whose change the document holds (a signature verified up
to it) is a fork: refused as forged, never as its actor's node's, not
told back in REFUSALS, and logged with the peer that brought it.
|
| |
|
|
|
|
|
| |
a_swarm_judging_every_change waited for c's forged write to be refused
by a, b and d each. The first to judge it tells c, which drops it before
the others may have it: wait for a refusal on any of them, then for c to
drop it.
|
| |
|
|
|
|
|
|
| |
In a_strict_swarm and sealed_values, c's forged writes were waited for
to be refused by a and by b. Whichever judges them first tells c, which
drops them before the other may have judged them (it waits for their
signature, or never gets them): wait for a refusal on either, then for
c to drop them.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A node refusing a member as a whole sent it nothing, and lifted that
only when a change of the member's was taken again. But a member that
dropped what was refused (REFUSALS) starts its sync sessions over, and
a fresh session sends no changes until the other side answers: the two
waited for each other, and the member stayed refused.
The refusal now notes the member's run and epoch_seq when it began; a
member with another document since (it dropped what was refused, or
rejoined) is synced with again.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The API checks the path a request asks for; the rules judge everything
the change does. Where they disagreed, the honest node's change was
refused by every other node, and with signatures required the node was
refused as a whole. The plan had both gates run the same judgement.
Under a policy, each change a node makes (its own writes and those
through the API) is now judged by rules::judge as receivers will judge
it, before it is signed or sent; one every node would refuse is rolled
back (the document forked at the heads before it, same actor: the
change never left) and the request refused with 403 (StoreError::
Refused). rules::judge_held, judging a change the document holds,
moves from swarm::refusals to access::rules for both.
The simulations that play a member past its own checks write with a
helper that bypasses them (forge).
Review finding 3 (the same judgement at both gates).
|
| |
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two writes the API lets a user make were refused by the rules:
* DELETE /peers/{pk}, with write on _continuum/forgotten alone, writes
the forget record and removes the member's entry in one change; the
rules wanted write on the entry. Removing an entry is now also taken
in a change forgetting that member, from a user who may forget it.
* DELETE /admin/users/{name}/tokens by a user who manages users writes
_continuum/logouts/<name>; the rules wanted write there. One who may
write _continuum/users may now write anyone's logouts entry.
Review finding 3 (DELETE /peers, revoking tokens).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A write makes the maps on its way where there are none
(store::write_path); the rules judged each made map as a write at its
own path, so a user whose capability lies below a map not made yet
(write on servers/eu, a first PUT at servers/eu/0) had its first write
taken by its node and refused by every other. A map made where there
was none, in a change writing within it, is now judged by what is
written within it.
Review finding 3 (parent maps created on the way).
|
| |
|
|
|
|
|
|
|
|
|
| |
Under a strict policy the rules read user data: the value at a signed
place (prev) and what holds one. A batch judged at its frontier missed
a signed write earlier in the same batch, so two successive signed
writes at one path received together were refused on some nodes and
taken on others. A change at, within or above a signed path now goes
in before the next is judged.
Review finding 2.
|
| |
|
|
|
|
|
|
|
|
| |
The rules read the policy at the change's dependencies only for strict
mode, so history from before the policy was judged by today's rules
when a late node caught up, or when REFUSALS had it judged again. A
change written while the document had no policy, or one this node
doesn't know, is now judged by none.
Review finding 6.
|
| |
|
|
|
|
|
|
|
|
| |
A node forgotten swarm-wide while alive cancels its forget record with
a change naming no user; the rules judged _continuum/forgotten by the
registry alone, so every node refused the cancellation and everything
the node wrote after it. A node may now write its own
_continuum/forgotten/<id>, as it may its member entry.
Review finding 4.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A REFUSALS naming the swarm's first change made the node receiving it
judge that change again in a document that isn't empty, refuse it as
"a change without dependencies that isn't the epoch's root", and drop
it with everything built on it: its whole document.
The first epoch's root is now the first change a document holds, as it
comes to an empty one or as it is in one; a change judged again on a
peer's word is never refused for having no dependencies; and
drop_taken refuses to drop an epoch's root, or anything that would
leave nothing kept, logging an error instead.
Review finding 1 (critical).
|
| |
|
|
| |
Flashes are drawn beneath the nodes' labels.
|
| |
|
|
|
| |
messages: off / dots / flash: a message expands at its own speed and
leaves an afterglow fading out in the direction it went.
|
