4656793ae0
Carousel §4.5 and §6.2 step 4: along their chain, a later schedule of one instance that keeps every earlier entry, with at least its passes at the same instants sending the same symbols, extends the one before it and may add objects. The last stands and the earlier are labelled `extended`. A schedule that drops an object, or withdraws, moves or changes a pass, still sets aside every schedule of its instance. Timeliness plans read the same schedule. Carousel §8.1 and §8.2: on an instance whose schedule stands, the publisher sends the group receipt, its claims from the head of their chain to the instance's last schedule, and the head of its origin's key log, at least once per the schedule's interval. A verifier given what a receiver acquired checks that it suffices: inband_chain_incomplete, inband_not_scheduled or inband_key_log_missing otherwise. Cache-authority §5.6, §7.2 step 4, §7.3 and carousel §4.3 step 2: a node states its plan for its own cache instance in a schedule claim signed by its own key. The cache verdict reads schedules, publisher's and nodes', sets aside another key's schedule of a node's instance (cache_schedule_signer_mismatch), and holds a statement of carousel §6.4 to the schedule that stands. A node's schedule credits nothing. Vectors for each rule in the carousel, timeliness and cache-authority corpora, verified by wai-rs and by the Python verifiers, each with mutated copies and weakened checks for the new rules. On the timeliness ladder: a plan and a run take a rung over a schedule a later one extends, a plan loses it over the same two withdrawing a pass, and timeliness §7.5.1 says a run does not date its claims. Co-Authored-By: Claude Opus 5.5 <[email protected]>
49 lines
3.6 KiB
Markdown
49 lines
3.6 KiB
Markdown
# live-conformance/cache-authority — who served what a node holds
|
|
|
|
The corpus of [`extensions/cache-authority.md`](../../extensions/cache-authority.md) §12, in one
|
|
file, `vectors.json`.
|
|
|
|
**Provenance.** Generated here by `wai_cache_authority_vectors gen` (`wai-rs`, feature
|
|
`cache_authority`), from Ed25519 keys on published seeds of one byte repeated 32 times
|
|
(jwp-receipts §7.8), constant instants, and envelopes of 2,000 bytes whose payloads are opaque test
|
|
bytes written by the generator; no media and no input from outside this repository.
|
|
|
|
`keys` names every key by its role, as 64 lowercase hexadecimal digits: the publisher `P`
|
|
(`did:web:publisher.example#d1`), the nodes `C1` to `C8` and the receivers `R1` to `R4` and `R9`.
|
|
`groups` gives the link hashes of `G` (four objects, the tallied group), `G9` (nine), `GL` (labelled
|
|
leaves), `GX` (a `group_start` that is not a date-time) and `GF` (four, its object 2 a floor derived
|
|
from its object 1). `heads` holds the two test logs' head revisions, of `https://operator.example`
|
|
and `https://other.example`; `C2` is in neither.
|
|
|
|
- `claims` (§5, a cache-transmission claim or a schedule) are each a `claim`, the signer's `earlier` claims in chain order, the `context`
|
|
it is checked against (a group receipt, another receipt, or `null`) and the `objects` held under
|
|
it; `outcome` is `accept`, `unchecked` (no group: it stops at step 5) or
|
|
`reject step=N reason=…`.
|
|
- `placements` (§4.4) are each a `key`, an instant `at_ms` and the `heads` named, keyed by origin;
|
|
`outcome` is the placement as §4.4 writes it.
|
|
- `verdicts` (§7) are each the `group`, the `objects` (receipt, and envelope or `null`), the
|
|
`claims`, a `sink`'s own instance, a statement offered (`assertion`), `count_only`, the
|
|
`heads`, and `held`: `null`, or carousel §6.4's statement with its bound and overhead,
|
|
`{"kind": "object", "bearer_id", "index", "by_ms", "loss_ppm", "overhead"}` or the same of
|
|
`"kind": "group"` with no `index`; `outcome` gives each object's and each claim's label, the
|
|
status, `sinks`, `whole`, `received_by`, the publisher's `bearers` and the `caches` that stand, the
|
|
sink's outcome, and each statement's (`holds` or `reject reason=…`), or `refuse reason=…` for a
|
|
group that fails.
|
|
- `tallies` (§8) are a verdict's inputs, the `acknowledgements` (each a record and its item lists,
|
|
in hexadecimal), the holdings `records`, the object's `index`, a `deadline_ms` or a timeliness
|
|
`deadline_claim`, the `region`, the `population` and `miss_target_ppm`; `outcome` is `met` or
|
|
`refuse reason=miss_target_exceeded` with §8.5's figures, or `refuse reason=…` for §8.2.
|
|
- `lines` (§9) are a verdict's inputs, acknowledgements and holdings records, a timeliness `claim`
|
|
and an `index`; `outcome` is timeliness §6.3's lines for that object's entry, from held-at
|
|
statements of all three kinds.
|
|
|
|
Everything is synthetic: keys attest nothing, both key logs are test logs, origins and bearer
|
|
instances are reserved example domains, and regions are ISO 3166-1's user-assigned codes. Each case
|
|
states the outcome it was written to have, declared in the generator, never copied from a
|
|
verifier. §8.1's bound of 1,048,576 keys is carried by no vector (32 MiB of hexadecimal); both
|
|
implementations check it themselves.
|
|
|
|
`wai_cache_authority_vectors verify` and `tests/cache_authority.rs` check that the file regenerates
|
|
byte for byte and that `wai-rs` reaches every stated outcome. `../cache_authority_verify.py` is the
|
|
second implementation, written from the extension's text, which also mutates copies of the corpus
|
|
and drops each of its own checks in turn and requires each to be caught.
|