open-standards/wai/live-conformance/cache-authority
Repository files (latest commit first)
Filename Latest commit message Latest commit date
2026-11-07 08:35:01 -05:00
..
README.md wai: a later schedule adds passes, what a receiver needs rides on the bearer, and a node schedules its own one-way sending 2026-11-06 18:09:38 -05:00
vectors.json Tariff version 7 bills a cache's own instance, an aggregated count and what an agent consumed, and a settlement declaration names its instance 2026-11-07 08:35:01 -05:00

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.