aboutsummaryrefslogtreecommitdiffstats
path: root/docs/api.md
Commit message (Collapse)AuthorAgeFilesLines
* sync: a delta's signatures as a blob of their owntv30 hours1-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | A sync message larger than the threshold for its peer (16 chunks, lower on a slow link or after a message to it failed whole) goes as a delta: the peer fetches its changes in chunks, from any node holding them. Its signatures, each writer's latest with changes in it, went in the envelope offering it: up to 65536 of them, 6 MiB, in one message, the size the delta exists to avoid. Nor did an Automerge message count its signatures (one per writer in a whole document pulled) towards the threshold. A delta's signatures are now a blob of their own: the offerer packs and keeps them (Blobs::keep, the latest 64), and the spec names them by BLAKE3 hash and size (DeltaSpec::signatures, None where no signature vouches for its changes). They are served as content (BlobId::Content), so their hash checks them. The receiver fetches them from the offerer alone, as another node holding the changes holds signatures of its own, before the changes, and offers them under the write lock just before judging the changes, so they wait for them as before. The envelope of a delta carries none. An Automerge message's signatures count towards its size: past the threshold, it goes as a delta. Wire version 49.
* signatures: a transfer carries one signature per writer in ittv4 days1-6/+9
| | | | | | | | | | | | | | | | | | | | | | Under a policy requiring signatures, a node takes a change only once a signature vouches for it: one of the change itself, or of a later change of the same writer. A writer is a node's run, each start, rejoin or drop making a fresh actor, so an epoch gathers writers for as long as it lasts, and a transfer of its whole history (a joiner pulling the document, a delta) must carry a signature for each of them, or the joiner waits for the rest for good. A message's signatures are now chosen by what it carries: * changes, up to 256 signed among them: each one's signature; * more (a whole document pulled): each writer's latest signed change among them, found by the document's change metadata (`Signatures::for_changes`), vouching for the rest; * a delta: each writer with changes in it (`get_changes_meta(from)`), its latest verified signature (`for_delta`). A message carries up to 65536 (6 MiB), and as many wait at the receiver for their changes (a delta's come after it). So a transfer leaves writers unvouched only in an epoch with more than 65536 runs writing since it began; a remake starts the count again. Wire version 48.
* docs: basic authentication sends the password unaskedtv4 days1-1/+4
| | | | | | | Review 4, 1269's note: the node challenges for a password (`WWW-Authenticate`) only what isn't a browser, by `Sec-Fetch-*` or a `Mozilla/…` user agent. A client calling itself Mozilla that waits for a challenge before sending its password would get none: api.md says to send the password with the request, as `curl -u` does, and why.
* docs: how signatures travel, as they do nowtv4 days1-2/+10
| | | | | | | | | | Review 4, appendix: api.md's Signed changes said a node passes on each node's latest signature (true of deltas, not of messages carrying changes) and that every change arrives vouched for. It now says what a message carries (its changes' signatures, each run's latest past 4096 and for a delta), that a node signs each of its runs' latest unvouched change at start and when its document is swapped (1277), and the two cases that still arrive unvouched (a change vouched for only by a refused one, postponed; more than 4096 runs writing in an epoch).
* sync: a message carries the signatures of its changestv4 days1-4/+5
| | | | | | | | | | | | | | | A sync message carried the signatures its peer wasn't sent yet, by a cursor per peer. Changes sent again, as after a message taken as delivered and lost on the way, went without them: the peer was past them. Under a policy requiring signatures they waited until the writer's next signed change, or the next session. A message now carries the signatures of the changes it carries (Signatures::for_changes), whatever the peer was sent before: changes sent again arrive vouched for as the first time. Past 256 (a message carrying the batches of many writers), each writer's latest instead, as a delta carries. The cursor goes, and with it resetting it after a failed send or a new session.
* docs: signing what is sent, and which --sign-every to choosetv4 days1-11/+28
| | | | | | | | | api.md's Signed changes says what sent, all and none do, what each costs, and which to choose: sent for nearly every swarm, all where each change should carry its own proof, none to save signatures where only protocol data and listed paths need them; and that signatures travel with their changes, a message carrying none taking none. access.md no longer says signatures come on their own within a second.
* docs: a signed null keeps the prev chain goingtv5 days1-1/+4
| | | | | | Review 3.1: a signed null stays as an envelope, so the value written after it names it in prev and an envelope from before the deletion can't be put back. api.md now says so.
* envelope: a signed value names its swarmtv5 days1-4/+6
| | | | | | | | | | | | 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.
* screen: a signature vouches for its change and what it builds ontv5 days1-2/+4
| | | | | | | | | | | | | | | 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.
* access: values sealed for their readerstv5 days1-0/+8
| | | | | | | | | | cs1.<age file>: a value encrypted with age to its readers' SSH keys, which no node decrypts. _continuum/access/sealed declares paths whose values must be sealed, for named readers or anyone; nodes check the recipients by age's key tags, at the API and on receipt. Auth plan M8, reworked: sealed values instead of containers, readers as users only (nodes hold no keys).
* api: signed values at the storetv5 days1-0/+30
| | | | | | | | | PUT with application/continuum-signed writes an envelope where values are signed (403/409 saying why); reads open envelopes and name the signer (x-continuum-signed-by), ?raw=true shows them. Under strict, unsigned writes reaching a signed value and the users API are 409. Auth plan M7.
* access: signatures requiredtv5 days1-1/+3
| | | | | | | | "signatures": "required": a change counts only once a signature by its committer vouches for it, and waits until then; every node then signs every change it makes. Auth plan M6.
* access: the policy enforcedtv5 days1-1/+1
| | | | | | | | _continuum/access/policy ({"version": 1}) has every node screen every change it receives, on every path changes come in. A policy a node doesn't know stops its writes through the API. GET /admin/refused. Auth plan M6.
* signatures: verified changestv5 days1-1/+2
| | | | | | | GET /admin/changes shows whether a signature by its node vouches for each change. Auth plan M5.
* signatures: on their own (SIGNATURES)tv5 days1-0/+2
| | | | | | | Signatures no sync message took go on their own within a second, to each peer not sent them yet (wire version bumped). Auth plan M5.
* signatures: with sync messagestv5 days1-0/+3
| | | | | | | Sync messages carry, for each actor's writes, the latest signature the sender checked; the receiver checks it once it holds the change. Auth plan M5.
* signatures: kept in the document filetv5 days1-0/+2
| | | | | | | A node's signatures are saved with its document (--document-file) and loaded with it. Auth plan M5.
* signatures: --sign-everytv5 days1-1/+4
| | | | | | | | Changes left unsigned are vouched for by the node's next signature: --sign-every 1s (default) signs the latest within a second, all signs every change, none only those that must be. Auth plan M5.
* signatures: changes signed by their nodetv5 days1-0/+18
| | | | | | | | | | Every node signs the changes it commits with its node key, an Ed25519 signature over the change's hash, kept beside the document. One signature on an actor's latest change vouches for its earlier ones. Protocol data and paths listed in _continuum/access/signed are signed, and writes with ?signed=true. Auth plan M5.
* docs: user names from the registrytv5 days1-3/+5
| | | | | | api.md names users as the registry has them. Auth plan M1 (docs).
* auth: logging in, and tokens as bearerstv5 days1-2/+3
| | | | | | | | | POST /auth/login (by htpasswd or the proxy), /auth/refresh, /auth/logout, GET /auth/whoami; every request may bring Authorization: Bearer instead of a password. --token-lifetime and --session-lifetime. Auth plan M2.
* access: authorization at the APItv5 days1-3/+8
| | | | | | | | | Every request is judged by the registry the node holds: store reads pruned to what the user may read, writes refused where it may not, admin endpoints by protocol capabilities. Without a registry, as before (--protocol-writers for protocol data). Auth plan M1.
* add stream heartbeattv10 days1-0/+3
|
* api: allow auth delegationtv10 days1-3/+4
|
* add documentationtv11 days1-0/+247