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

The corpus of [`extensions/peer-delivery.md`](../../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/`](../../wai-web/peer/).