open-standards/wai/live-conformance/peer-delivery/README.md

live-conformance/peer-delivery — objects from the neighbours that hold them

The corpus of extensions/peer-delivery.md §10, in one file, vectors.json.

Provenance. Generated here by wai_peer_delivery_vectors gen (wai-rs, feature peer_delivery), from Ed25519 keys on fixed 32-byte seeds, constant instants, and envelopes 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's (did:web:publisher.example#d1), five holders' (h1 to h5) and the asker's.

• world.groups are two groups: each its link hash, its group receipt, and its objects, each an object receipt and the envelope in hexadecimal. The first has six objects; the second three, its second past one data frame.
• frames (§4.2) are each a message's bytes and its outcome: read, with the frame's name and fields; or refuse and its reason.
• transfers (§4.4) are each what was asked, the asker's max_object_bytes, the head and the lengths of the data frames that follow; outcome is complete or the reason.
• gates (§3) are each a policy and a setting; outcome says whether the sink may ask and may serve.
• sessions (§5, §6.1) are each an asker's session: its test asker_seed, the policy and setting, the groups and objects (by index into the world) whose receipts it holds, what each holder's link answers for an object (links, by holder key and <group>/<index>: serve the object named, bytes given, or miss with its code; a link with no answer failed), and rounds, each the records offered before it, its instant, the wanted objects and its window. outcome.rounds gives, for each round, the records' labels, each wanted object's route, attempts and source (from: a holder's key, or origin), and the acknowledgements signed, each its upstream, record and items; outcome.asks counts the objects each holder was asked for, and outcome.records gives the labels after the last round.
• answers (§4.3) are each a holder's record, an object and whether it is permitted and holds the bytes; outcome is serve or miss code=….
• acks (§6.3) are each a holder (me), the item list of what it served over a link, and an acknowledgement record with its items; outcome is taken with what the record states, or refuse and its reason.

Everything is synthetic: keys attest nothing, and the publisher's origin is a reserved example domain. Each case states the outcome it was written to have, declared in the generator: a session's attempts, sources and labels are written out by hand there, and its acknowledgements are sealed from the objects the case says each holder served, never copied from the client.

wai_peer_delivery_vectors verify and tests/peer_delivery.rs check that the file regenerates byte for byte and that wai-rs reaches every stated outcome. ../peer_delivery_verify.py is the second implementation, written from the extension's text, which rebuilds every acknowledgement byte for byte, mutates copies of the corpus and drops each of its own checks in turn and requires each to be caught. The page client's runs over this world are wai-web/peer/.