Transaction-Science/open-standards
Watch
1
0
Fork
You've already forked open-standards
 0
Code Issues Pull requests Projects Releases 17 Packages Wiki Activity Actions 79
open-standards/wai/live-conformance/cache-authority/README.md
Transaction Science 4656793ae0 wai: a later schedule adds passes, what a receiver needs rides on the bearer, and a node schedules its own one-way sending 
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]>
2026-11-06 18:09:38 -05:00

3.6 KiB
Raw Permalink Blame History

live-conformance/cache-authority — who served what a node holds

The corpus of 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.