WLK1 for the link record, wai identify, the carousel schedule and holdings (replaces #604 and #605) #611

Merged

dcharlot merged 8 commits from wai/inspect-carousel-holdings-b into main 2026-11-04 07:18:17 -05:00

Conversation 0 Commits 8 Files changed 638 +44442 -171

2026-11-04

Transaction Science

wai: holdings — which objects of which groups a node holds now, for its neighbours ...

A receiver that stores what a broadcast carried, a neighbourhood cache or a peer can serve those
objects over a short link; a neighbour that knows who holds what fetches from them before it spends
the backhaul. Nothing said who holds what.

extensions/holdings.md registers `wai.delivery.holdings`: a record (WHD1) of, per group a node holds
objects of, the group's link hash, its leaf count and either `whole` or a bitmap (as a
reconciliation's), in one canonical form, with the instant it states them at and the one it expires
at, signed by the holder under SPEC §7 Signatures. Groups and bitmaps rather than a filter over
hashes: WAI delivers everything under group receipts that name objects by position, a node holds
objects as groups arrive, and a bitmap is exact (no neighbour sent after an object its holder
lacks) at a bit an object, 41 bytes for a group held whole.

A verifier holds a record to its instant and to the group receipts it has (a misstated leaf count
refuses it whole; a group with no receipt held is kept), keeps a holder's latest record and sets
aside two of one instant that differ, answers whether a record holds an object, and derives an
asker's plan: each wanted object's holders in the asker's order, and the objects no neighbour holds,
which come from the origin. An object a neighbour serves is verified under its receipts like any
other; a record is never evidence of bytes. A node advertises only what reached it over a broadcast
bearer, and may sign each record with a fresh key.

The reference is the `holdings` module of wai-rs; the corpus is live-conformance/holdings/ (21
records with a control for each rule, 11 verdicts, 6 queries, a plan over three neighbours), with
holdings_verify.py as its second implementation: 39 cases agree, 9 of 9 mutated copies and 10 of 10
weakened verifiers caught.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

36f5074b4c

• View at this point in history

2026-11-04 05:20:31 -05:00

Transaction Science

carousel §11: the patents disclosed on RaptorQ and Raptor, and no-code as the default ...

The IETF holds disclosures on RaptorQ (RFC 6330; #2554 current, updating #1958) and on Raptor
(RFC 5053; #1957 current, with #1176 the holder's general licence statement). Both current
ones give two terms by product: a licence within the holder's standard terms for a device that
implements a wireless wide-area standard, and a non-assertion, conditional on full
implementation and suspended against a party that asserts, for one that implements none. No
disclosure relates to RFC 5445 or RFC 5052.

§11 cites them by number and states each licence class as disclosed. Since neither code is
royalty-free for every implementer, no-code is the default a tool that writes schedules uses,
as SPEC §5 keeps a capability that is not royalty-free from being a default. The reference
implementation encodes and decodes no symbol; its RFC 6330 decoder is a development dependency.
Security and privacy considerations move to §12; nothing cites them by number.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

d93ca3327a

• View at this point in history

2026-11-04 05:20:31 -05:00

Transaction Science

wai: the carousel schedule — when each object passes on a bearer with no return path, and when a receiver holds it ...

On a bearer with no return path a receiver cannot ask for what it missed: it holds an object
only if the passes it heard carried enough encoding symbols. bearer-receipts declares the
transmission and reconciles it afterwards; nothing stated the plan in between.

extensions/carousel.md registers `wai.bearer.carousel` and the jwp-receipts claim class
`schedule` (§2.4.16): a publisher's signed plan, beside the group receipt and the instance's
transmission claim, naming for each object its forward error correction (RaptorQ, RFC 6330 with
its verified erratum 5548; Compact No-Code, RFC 5445) and that code's object transmission
information, the repair symbols each pass adds, whether later passes repeat their ESIs or send
new ones, and the passes' times and count. Step 4 holds each code's parameters to its bounds
and division into source blocks; step 6 holds the entries to the group, its objects' content
hashes and, where the bytes are held, their lengths.

From it a verifier derives, for a loss bound in parts per million, the pass after which a
receiver whose losses stay within it holds each object, for every pattern of loss within the
bound: a RaptorQ block at K' + h distinct symbols, the count RFC 6330 §5.8 states its decoding
failure bound at, and a symbol a repeating pass missed counted as missed again. It checks a
statement that an object or a group is held by an instant, sets aside schedules that contradict
each other or whose instance is undeclared or two-way, and a receiver derives the passes it
must listen to and how long its radio must be on.

The reference is the `carousel` module of wai-rs with the class's body in
`claim_receipt::schedule`; the corpus is live-conformance/carousel/ (33 verdicts, 50 claims, 16
plans) with carousel_verify.py as its second implementation and claim_verify.py's new
`carousel` mode for steps 1-4. tests/carousel.rs checks K' and Partition[] against an
independent RFC 6330 implementation (a dev-dependency) for every block size, and decodes each
RaptorQ object a case holds available from what a receiver within the bound holds. A receipt
index served over HTTP now checks a schedule claim against its group and listed objects.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

e2a7bfb87f

• View at this point in history

2026-11-04 05:20:31 -05:00

Transaction Science

wai mcp: media_inspect is in the core toolset's list ...

The core toolset serves media_inspect after envelope_inspect; tests/cli_mcp.rs and the
README's toolset table now name it in that place.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

3d42de258e

• View at this point in history

2026-11-04 05:20:15 -05:00

Transaction Science

int_kernels_vectors: the identify corpus decodes nothing ...

every_decoded_output_states_a_sha256 requires each conformance directory to state its decoded
outputs' SHA-256 or say why it has none. identify-conformance decodes nothing: each vector states
what a file's bytes are read as, and the file's SHA-256 in vectors.json.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

03575317a2

• View at this point in history

2026-11-04 05:20:15 -05:00

Transaction Science

wai identify: what any file is, from its bytes alone ...

`wai inspect` reads envelopes; most files a toolchain meets are not envelopes, and the
first question about one is what it is. `wai identify <file>` (operation media.inspect,
extensions/media-identify.md) answers it for any file:

- the formats the bytes fit, each with the offsets of the bytes that say so, how far its
  structure was followed and where and why that stopped;
- a container's tracks as it states them: codec, size, channels, rate, protection;
- the registered capabilities they map to, and what a format probe reads of them;
- signatures found inside the file;
- where no format is recognised, measures that still hold: how the byte values are
  spread, uniform windows, and the lags at which the bytes repeat.

The verdict is identified, ambiguous, signature_only or unknown, and there is no
confidence figure: a candidate's strength says what was checked. Nothing is decoded, no
protected track is opened, and unknown stays unknown. Walks cover ISO media, Matroska,
transport streams, Ogg, FLAC, RIFF, MPEG audio, ADTS, PNG, JPEG, GIF, IVF, YUV4MPEG2,
FLV, AV1 OBU and Annex B streams, and HLS and DASH text; 35 more formats are known by
their signature. Every walk is bounded, reads a file where its lengths lead (a large file
is never held whole), and has been given hostile bytes; it builds for wasm32.

The agent door has it as media_inspect, its results marked untrusted_content: a file's
author chooses the strings in it.

identify-conformance/ holds files written by real muxers and encoders from test patterns
and tones, what an independent media prober reads of them (prober.json), and generated
cases sitting on each rule's edge. identify_verify.py is a second implementation written
from the text; it reads the extension's tables, gives every file its whole result, and
holds ext/ to the prober's reading. tests/identify.rs holds the reference's tables to
the extension's.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

2fd26925d3

• View at this point in history

2026-11-04 05:20:15 -05:00

Transaction Science

live-recording: a record with the link record's magic, WLK1, is not a clip record ...

The link corpus refuses a part that bears the clip record's magic; this adds the reverse.
The live-recording corpus gains the clip link_record_magic: chunk 4's clip record beginning
WLK1 and signed under it, so the magic is its one defect, refused malformed at the clip
(§5.2, which now names WLK1 among the other magics). wai_live_record_vectors writes it;
the README lists it.

live_record_verify.py requires the same refusal, malformed at the clip, of a copy of each
accepted clip given WLK1, so a verifier that reads past the magic to the signature fails.
The CHANGELOG entry for WLK1 says so.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

673554abf0

• View at this point in history

2026-11-04 05:19:53 -05:00

Transaction Science

live-contribution: the link record's magic is WLK1, no longer the clip record's WCL1 ...

The contribution link record and the live-recording clip record both began WCL1. The clip
record had it first (live-recording §5.1, the registry's only WCL1 row); the link record took
the same four bytes when it was added, so a reader that tells records apart by their magic
could not tell one from the other.

The link record is now WLK1, a magic nothing else in the registry, the code or an open branch
uses. live-contribution §6.2 and SPEC name it, §6.5 step 2 says the clip record's WCL1 is
refused as malformed, and codecs/registry.rs registers it (REGISTRY.md and registry/ exported
from it). joule-moq-ingest writes and reads it. The corpus live-conformance/links/ is
regenerated with it, its files now .wlk1, plus clip_record_magic, a part with the clip
record's magic, refused. live_contribution_verify.py reads WLK1 and also refuses each accepted
part mutated to WCL1.

A wire change: a link record written before this one is malformed to a reader of this
revision. The CHANGELOG says so and acknowledges every corpus file that changed.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

57e426c940

• View at this point in history

2026-11-04 05:19:53 -05:00