| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A remake that names all users names those that count in its
proposal's history, and still do at its base: the list is fixed with
the proposal, so those who vote see it, and a user brought in while
the votes run isn't on it. A fork's voters go the same way.
And what reading the design from end to end found:
* a remake does two things, not one: it throws history away and names
who votes next;
* nothing plain is written but a node's member entry and its records
of proposals, said where namespaces are, too;
* a node doesn't sync under a policy it doesn't know, whatever its
version says;
* two sides that only resolve differently show by their stamps;
* on the wire a federated swarm's handshake says which epochs a node
keeps, and a version speaks the one before its own: "no message
changes" holds for a swarm that isn't federated;
* three more things assumed: what was seen for long kept as the node
goes, the cost of a digest with every stamp, two wire versions
spoken at once.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
What the maintainer asked of the design:
* Who votes is named by the remake's proposal: all users at its base,
as recommended, or a list. So those who vote say who votes next,
and nobody votes by a rule of who created it. What that costs is
said with it: every voter named counts toward what a decision
takes, and all users is whoever brought users in.
* What a policy no longer covers is uncovered at once where the
decision holds: shown aside by every node, taken away by its user
only, changed by nobody, and dropped once it has been seen there
for `uncovered` (a number; 0: at once). Within an epoch a rule
moves nothing in the document; the remake moves it.
* Being seen takes nothing but a node that is up: its stamp is
renewed about daily whatever else is written. A node left running
keeps its voter present; naming the voters deals with that.
* A release of a vote is best effort.
* Continuum changing under a swarm: versions agree by what they
compute, not by a number. Every stamp carries the digest of the
snapshot its node would build there; a remake is taken up by the
ID each node built; a node checks itself against the swarm before
it writes with a new version; a change of the rules is a change of
policy, and a node knows a policy by everything in it; recorded
vectors every version passes. What can't change, what changes
freely, and when it is a fork.
* Who may connect is outside the design; the swarm key is a note.
The attacks are 84.
future-work.md: several roots, present by the user's own signature, a
guide to moving to another swarm.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
What the maintainer asked of the design, and what it changed:
* Lines. A user is in while it has a line: a chain of creations and
vouches from the root. When its creator goes, one that another
vouched for stays without doing anything. The witnesses of its
claims are the users on the lines it stands on: its creation's, and
those of vouches it accepted (`accept`), so nobody gets a say about
a user's names by vouching for it unasked. Why only its signer
takes a vouch back is said where unvouching is.
* Lengths of time are read between two stamps of one node, with what
that node had seen at each: a voter is absent once a third of the
voters saw it silent for long, a user gone once they saw it out. No
clock is set against another, and why a third.
* Decisions. A proposal is decided as soon as the nodes of two thirds
of the voters hold its votes: at once, not at the end of a window.
Any number are open at a time, within a limit a voter. Of the
decisions of one matter the last holds, by which proposal was made
in sight of which, so two decided at once stop nothing. A remake's
base is named by its coordinator, a node of the proposer.
* The policy changes by a decision, as a whole, with no remake: a
remake throws history away and does nothing else. What a policy no
longer covers doesn't count, and a remake keeps it aside for an
epoch or drops it, as the policy says. Going apart by a fork stays
for those a decision leaves behind.
* What a remake leaves out, so that the document's size goes by what
stands: a release is a statement in its epoch, the remake deletes.
* Names are written as they are used, in the document and in the
rules alike, and compared by their segments: structure, not
meaning. A rule may leave a name to the voters to give.
* Who vouched for whom changes nothing in who connects to whom: a
node keeps its seeds and its user's other nodes as neighbours.
The attacks are 83, the stages fifteen.
future-work.md: guides to write (keys, the root, starting a swarm,
voting, a registry), policies merged.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
What the maintainer answered to the design's last two questions, and
what follows from it:
* The fractions are numbers of the policy like the others, changed by
a decision to any value: the share of the voters present a decision
takes (two thirds recommended), the share of all of them (half), and
the share whose stamps make the swarm's time and a user gone (a
third). What is promised of decisions is argued for the recommended
ones; Why it holds says what other values carry.
* Refusing a decision: a node follows every decision that counts
unless its operator has it refuse, by bounds on the policy's numbers
or by hand. It then moves to the epoch built at the decision's
history without it, which is the same for every node that refuses
the same decision: those who think alike go on together without
arranging it. While a proposal's votes run, a node whose bounds it
breaks says so. A remake or a change of policy is refused by
staying.
* A decision gives a user name with its namespace, as designed.
* No open question is left. The options not taken that the questions
listed are among the roads not taken: first users voting as soon as
created, voters let in without a remake, other reaches of an
unvouch, a gone user coming back, first keys by those who vouch,
a registry of only what is signed, numbers the design fixes.
The attacks are 78; the stages name them by their numbers.
future-work.md: bounds on more than numbers.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
What the maintainer answered to the questions the design had left:
* Every quantity of the design is a number of the policy, in one
table with what the design recommends (the times, the limits, how
much a remake's base may lack, how long the root's node lets a claim
wait). The genesis policy sets each, and a decision changes any to
any value: nothing constrains them. The fractions aren't numbers.
* While a user is out, the voters free its names or give them to
another by a decision, whatever `gone` says; a policy without `gone`
has the names wait until a vouch or a decision.
* Nobody is put out by a vote, said where unvouching is, with what
there is against a user that harms within the rules.
* A node keeps the epochs it left for as long as its operator says,
`archiveRetention` at least, and says which; so a node coming back,
or one joining from the genesis root, walks every epoch where an
archive is within reach, and shows where the walk doesn't end at its
peers' epoch.
* Settled, and listed so: who votes, from where an unvouch undoes,
gone for good, first keys by a decision, what the root holds
unsigned. Two questions remain: whether the fractions are numbers
too, and whether a decision gives a user name with its namespace.
future-work.md: an archive of every epoch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
What the maintainer answered to the design's open questions, in the
design:
* The numbers. The limits and the times are the policy's numbers, set
in the genesis policy and changed by a decision: 64 keys, 64 nodes
and 256 addresses a user for a start; `window`, `absent`, `gone`,
`archiveRetention`. A lowered limit takes nothing away.
* A user nobody vouches for is out, and its names wait for it: nobody
else claims them. Out for 30 days, as the stamps of a third of the
voters show, it is gone: its names are free, and no vouch brings it
back. So whoever relied on a vouch that an unvouch or a cut took
back has that long to find another, and loses nothing meanwhile.
* First keys by a decision. The voters are above every user's first
keys: they give a user that lost them new ones, with a cut for the
old. The promises say so, and what isn't promised: a name against
two thirds of the voters.
* What a decision is made of (a proposal, a vote, its release, the
decision) is taken in any node's change, so a user without a node
votes at whatever node it reaches, or by a vote carried to one. Such
a user names another party's node to carry for it.
* Coming back after remakes: by the archives on nobody's word, epoch
by epoch, as far as peers keep them; else by an ID the operator
gives, never because peers advertise an epoch. A statement is
carried over from the epoch before only; older ones are quarantined
for the user to sign again.
* Resolving reads the decisions first: nothing below changes them.
* The questions that remain are put with their options: who has a
vote and from when, whether the voters put a user out against those
who vouch for it, from where an unvouch undoes, whether gone is for
good, the price of first keys by a decision, and what the root
holds unsigned.
The attacks are 76; the stages name them by their numbers.
future-work.md: barring a user by a decision, and voting made easy for
a user without a node.
|
|
|
federation.md designs what the krebs registry needs of continuum: a
swarm several parties keep, any of them possibly malicious. Nothing of
it is built. It is a mode a swarm is started in: one that isn't
federated stays as it is.
* The parties, what an adversary can do, and what is promised to an
honest node: only valid changes; the same document and the same
resolved registry for the same changes; values signed by their users;
one holder per name; a claim nobody takes once the root's node saw
it; no waiting for anyone to write; and, with fewer than a third of
the voters present malicious, decisions by two thirds of them. And
what isn't: one history under a partition, a name never contested,
decisions against a third, against keys stolen later, against a
malicious voter on both sides of a long partition, or with half the
voters gone; a swarm no forked actor splits.
* The design, on the strict policy. The policy is in the root. Users
come by statements that only add; a user is its creation, its keys a
tree, its nodes those it names. Vouching and the line; unvouching,
with what exactly it takes back. A namespace per user. Names of
declared kinds claimed, with rules and limits as data, some kept for
a user without a claim. Of two claims out of each other's sight, one
is late where its own side can be shown to have seen the other
first; where that leaves not exactly one, the name is contested, and
a release gives it up. Cuts: what a key signed outside a set of
changes stops counting, whenever it shows up; a key is cut off by one
above it only. Bans change what those who follow read, not what
anyone takes.
* Decisions: votes signed by the voters, over days, by numbers the
document holds and a decision changes. Who votes is in an epoch's
root change: the root alone at first, then, with each remake, the
users a root created, so nobody fills the votes without two thirds
of those there agreeing. A time read from the document, by which
those away for long don't count; a decision taken up by the voters'
nodes while its votes run, and counting with two thirds of those
present and more than half of all, so that honest voters never make
two however long a partition lasts. The
root's seat given anew by a decision, and what a root finds when it
comes back. Remakes: the base is the decision's history, every node
builds the snapshot from the registry as it resolves, statements are
carried over, and what counted at the base is final. A change of
policy as a fork each operator follows or not, as Bitcoin changes
its rules; it may name who votes on its side, and is the way out
for those a decision leaves behind.
* What every node judges and how the registry resolves, how a partition
shows and how a side comes back, links along the line, tokens of
one's own party only. Why the promises hold, the roads not taken,
what members are trusted with then, what is continuum's and what the
application's, 69 attacks with the tests that show them, the
registry's layout with moving in and writing out, fourteen stages,
and ten open questions with a choice for each.
future-work.md gets what the design leaves.
|
