WAI Extension: Native Sink

Mirrored from the canonical text at commit 260cbd09 (2026-11-08).

Status: Draft. What a native host, an application that plays a stream through its platform’s own player, does so that the stream is verified where it carries WAI’s receipts and evidenced as stream-audit evidences a page’s playback. The platform’s player decodes on the platform’s media engine and is not changed; the sink sits on the path its requests take and, for one playback session: verifies a media playlist against its playlist receipt and the chain of its live revisions (http-delivery §8.6), holds an object whose name states its content hash to that hash, and tells the host, object by object, whether it may hand the bytes to the player (§4); signs, under a fresh key per session, what stream-audit has a player sign: settlement acknowledgements of every object it received, a presentation claim for each ad the stream marks, and the session record, with the energy of each role and its acquisition class or the unmetered marker (§5, §7); ends a session nobody can see, or whose viewer has gone idle (§6); and hands the host the bundle for the owner’s collector. One C interface serves every native platform (§9). No new record, no new transport and no change to the wire format. The reference implementation is the native_sink module of wai-rs and its C interface ffi_sink (feature native_sink, header include/wai.h); the Swift package wai/wai-sink-swift integrates it with the native player of the platforms whose language it is, and the Kotlin library wai/wai-sink-android with the media player library of the phone and television platform whose applications are written in Kotlin; the corpus is live-conformance/native-sink/, and its second implementation is live-conformance/native_sink_verify.py. Keywords MUST, MUST NOT, SHOULD, MAY are RFC 2119/8174.

Texts this revision relies on: the WAI texts it cites; draft-pantos-hls-rfc8216bis-22 §4.4 (the playlist tags a sink reads: EXTINF, EXT-X-MAP, EXT-X-KEY, EXT-X-SESSION-KEY, EXT-X-PROGRAM-DATE-TIME, EXT-X-DATERANGE, EXT-X-ENDLIST, EXT-X-STREAM-INF) and §4.2 (attribute lists); RFC 3339 §5.6 (date-times); RFC 3986 §5.2 and §6.2.2 (resolution and normalization); RFC 6454 §6.2 (the ASCII serialization of an origin); RFC 9110 §8.4 (content codings); RFC 8032; FIPS 180-4; and the BLAKE3 specification. A section number in this text is this extension’s unless it names another document.

1. Scope

In scope: the session and its configuration (§3); what a sink reads of a playlist, how it verifies a playlist and an object, and what a host does with the answer (§4); the observations a host gives and the log they make (§5); the rule that ends a session nobody can see (§6); the energy a native host states (§7); the reasons (§8); the C interface (§9); and conformance (§10).

Out of scope: a transport; the records the sink signs, their verification and the channel report, which stream-audit defines; the playlist receipt and its chain, which http-delivery §8.6 defines; the player itself and its decoder; the collector; and how a host routes its player’s requests through the sink, which each platform’s integration states (§4.4).

Relationship to the core spec: this extension registers nothing. It is a profile of stream-audit for a native host, with verification added from http-delivery and packaging, and the C interface that every native integration shares.

2. Terms

• Native host: an application on a phone or tablet, a television or set-top box, or a computer, that plays a stream with the player its platform provides.
• Player: the platform’s player. It requests the playlists and segments of an HTTP presentation, decodes and presents them; this extension changes nothing in it.
• Sink: the code of this extension, in the host’s process, on the path the player’s requests take: the player asks the sink, the sink fetches, verifies and answers (§4.4).
• Session, channel, owner, session key, object, origin: as stream-audit §2 and §3 define them.
• URL key: an object’s URL after redirects, resolved against itself and normalized as http-delivery §11.5 does (RFC 3986 §5.2 and §6.2.2), without its fragment. Two spellings of one URL are one key.
• Content hash: of a WAI object, jwp-receipts §2.1’s, BLAKE3("moq-jwp:object\x01" ‖ envelope); of any other object, its SHA-256 (settlement §14.1).
• Time is microseconds since 1970-01-01T00:00:00Z on the host’s clock; a media playlist’s program time is milliseconds on the same scale.

3. The session

3.1 Configuration

A host opens a session with a JSON object of these members; channel and owner are required, every other has the default shown, and a member not listed, or a value of another type, is refused (native_config_invalid):

3.2 The session key

A sink MUST make a fresh Ed25519 key for each session from its platform’s random generator, as stream-audit §3.2 requires, and MUST NOT derive it from an identifier of the viewer, the device or an account. The C interface takes a 32-byte seed in its place for conformance vectors and tests only (§9); a host MUST NOT pass one for a viewer’s session. The session is stream-audit §3.2’s, over the channel id and the key.

3.3 Lifetime

The session’s log opens with a start observation at the time the session opens (§5.2). The session ends when the host ends it (§6), and then signs its records once. Every call after that is refused (native_session_ended), so no record can be signed twice for one session.

4. Verification

4.1 Reading a playlist

A sink reads a playlist as a player does, line by line (a line ends at LF; a CR, space or tab before it is not part of it), and refuses (playlist_malformed) one that is not UTF-8, is longer than 16 MiB, or whose first line, after an optional byte order mark, does not begin #EXTM3U. A playlist with an EXT-X-STREAM-INF or EXT-X-I-FRAME-STREAM-INF line is a multivariant playlist, and the sink takes nothing from it but that. Of a media playlist it reads:

• each media segment: the URI line after its EXTINF, resolved against the playlist’s URL key (§2); its duration, the EXTINF value as a decimal number of seconds read exactly and rounded half up to the millisecond (a value that does not read, or reads as 0, is 1 ms); and its program time, the last EXT-X-PROGRAM-DATE-TIME before it plus the durations of the segments since;
• the URI of EXT-X-MAP, and the URIs of EXT-X-KEY and EXT-X-SESSION-KEY, resolved so;
• each marked ad of stream-audit §6.1: an EXT-X-DATERANGE with SCTE35-OUT or SCTE35-CMD, or a CLASS the configuration names, whose START-DATE reads and which has a DURATION (or a PLANNED-DURATION), its marker the line as the playlist carries it;
• whether it has EXT-X-ENDLIST.

An attribute list is read as draft-pantos-hls-rfc8216bis-22 §4.2 writes it: a name of upper-case letters, digits and -, =, and a quoted string or a value up to the next comma. A date-time is RFC 3339 §5.6’s date-time with an upper-case or lower-case T and Z, its fraction truncated to the millisecond. These readings are the ones stream-audit’s integration reads, so that the page and the native host name the same segments and the same ads.

4.2 A playlist and its receipt

Before it hands a media playlist to the player, the host fetches the playlist’s receipt file, mr/<BLAKE3 of the playlist's bytes>.json resolved against the playlist (http-delivery §8.6), and gives the sink both; a receipt that is not served is given as none. Then the sink, in order:

1. reads the playlist (§4.1);
2. with a receipt: checks the playlist against it as http-delivery §8.6 checks one (playlist_receipt_malformed, playlist_receipt_mismatch, playlist_receipt_invalid), and then takes it into the chain of receipts it holds for the playlist’s URL key, as that section takes a live revision (playlist_receipt_unchained, playlist_receipt_parent_missing, receipt_name_mismatch, playlist_receipt_walk_exceeded, playlist_listing_rebound). Where the chain needs a parent receipt the sink does not hold, it answers with that parent’s name, mr/<hash>.json, and takes nothing: the host fetches it relative to the playlist, gives it to the sink (or says it was not served), and gives the playlist again;
3. with no receipt: refuses it (playlist_unsigned) when the configuration requires signing;
4. takes it: the playlist is signed when its receipt verified and chained, and listed otherwise. Its segments, its initialization section, its key URIs and its marked ads join the session, each segment and initialization section listed by its URL key, as signed or listed.

A refused playlist joins nothing, and the host MUST NOT hand it to the player. A multivariant playlist is listed, never signed: http-delivery §8.6 signs media playlists only.

4.3 An object

The host gives the sink every response body the player’s requests received, with its content codings removed (RFC 9110 §8.4), its URL after redirects, the time its body was complete, its status, and whether it is media where it knows (an initialization or media segment; otherwise the playlists it took say so). The sink:

1. keys: an object whose URL key is a key URI a playlist named is a key or licence response: it is not acknowledged, not logged and not checked (stream-audit §4.1);
2. what its name states: the object’s content hash is checked against the hash its URL states, and an object whose bytes are another’s is refused (object_digest_mismatch):
   • a cid: the one the playlist line that lists the object states, its fragment’s cid (http-delivery §3.1) or else a last path segment <64 hex>.wai (http-delivery §5.2); else the one the object’s own URL states in the same way; against the object’s jwp-receipts §2.1 content hash;
   • a SHA-256: a last path segment of 64 lowercase hexadecimal digits, a dot and an extension of letters and digits other than wai, the name a floor fragment has in packaging §7 (floor/<id>/<SHA-256>.m4s), against the SHA-256 of the bytes, where a signed playlist lists the object or the configuration says content_addressed. Under a listed playlist and without it, such a name binds nothing: a stream another service packages is never refused for what its names look like;
3. signing required: under a configuration that requires signing, an object that no signed playlist lists, and that is not itself a playlist the session took, is refused (object_unsigned);
4. a playlist’s body: an object that is the body of a playlist the session was given (by URL key and BLAKE3) is listed as that playlist was, and refused when it was refused;
5. received: every object but a key, refused or not, is acknowledged and logged as stream-audit §4 and §7 say. An acknowledgement states what was received, not what was presented.

The answer states the object’s SHA-256; its cid, where its URL states one; how it is listed (signed, listed or unlisted); what bound its bytes (cid, sha256 or none); whether it is media; whether it is a key; and the refusal, or none.

4.4 What a host does with an answer

A host routes the player’s requests through the sink: a server on the loopback interface that the player is given in place of the origin, or the platform’s hook for loading a player’s resources, whichever the platform lets the player use for every request of an HTTP presentation. For an answer that refuses, the host MUST NOT hand the bytes to the player; it answers the player’s request with a failure (the loopback server with status 502), and the player reacts as it reacts to a failed request. A host MAY fetch the object again from another origin the presentation names; the second response is an object of its own. A host MUST NOT answer the player with bytes the sink was not given.

What a verification establishes is http-delivery §11.6’s: an object listed by a signed playlist and bound by its name is what the playlist’s signer published; one listed, only what the origin that served the playlist named. Nothing here makes a third party’s stream signed: such a stream is acknowledged, and evidenced, as stream-audit says.

5. Observations and the log

5.1 Observations

While the player presents, the host gives the sink an observation at least every 200 ms, and on each change of playback, visibility, audibility, rate or position, as JSON:

The sink builds the record’s spans from them as stream-audit §5.2 does, and each marked ad’s claim spans as ad-presentation §10 and stream-audit §6.3 do. An observation with a member not listed, or t_us or visible_bp missing, is refused (native_input_invalid).

5.2 The log

The sink keeps stream-audit §7.1’s observation log. It opens with start when the session opens (§3.3); the host logs present when the player shows its first frame, stall-start and stall-end around each stall, and end or abandon when it stops. Where the host logged no present, the first observation that is playing logs it; where it logged neither end nor abandon, ending the session logs end for a session that ended ended and abandon for any other. An event of another name is refused (native_input_invalid). A log’s times never decrease and nothing follows its end or abandon (delivery-telemetry §7.1): an entry made at a time before the last entry’s, which a host’s player and its requests, on threads of their own, make, is logged at the last entry’s time; and after end or abandon the log takes nothing, while an object received then is still verified and acknowledged. The host sends the log’s Event-mode CMCD reports to the owner’s collector as it plays (stream-audit §7.2).

6. Ending

6.1 The termination rule

A sink ends a session that nobody can see or that nobody attends to, by the host’s configuration:

• hidden: unseen_grace_ms is above 0, and the stream has been unseen (an observation that is playing with visible_bp 0, and none since with visible_bp above 0) for at least unseen_grace_ms;
• idle: idle_ms is above 0, and the last observation with interaction, or the session’s start where there is none, is at least idle_ms before.

The answer to the observation that meets a rule names it. The host then MUST stop the player’s requests for the stream (it stops the player or removes its item, so no further segment is fetched) and end the session with that reason (stream-audit §8.2). A host that keeps the audio of a presentation playing while its video is hidden ends the video’s session and keeps the audio’s.

6.2 What a native host observes

A host states what its platform reports and claims nothing it does not: a platform that does not report occlusion has its window’s place on the screen, not what other windows cover.

7. Energy

A session opens with the unmetered marker for the sink decode (role 3) and the display (role 4), and no entry for the origin (role 1) or the delivery (role 2): stream-audit §8.1’s rule for a sink with no meter. A host states a role’s figure with its acquisition class only when a counter or a model covers that role’s work (energy-measurement §2), replaces a marker with it, or removes a role’s entry where it knows nothing of the role. A figure of 0 with a class, or above 0 with none, and a class energy-measurement §2.7 refuses, are refused (native_input_invalid).

The platform’s player decodes on the platform’s fixed-function decoder, in a process of the platform’s, which no energy counter an application can read covers. So a native host that plays through it states the sink decode as the unmetered marker, never as a figure of its own process’s counter: that counter covers the host’s own work (its requests, its hashing, its signing), not the decode. A host that decodes in its own process, a WAI-native capability decoded through wai-rs for example, states the reading of a counter that covers that process, with its class and evidence. The display is the marker unless the host holds a figure for the panel with its class.

8. Reasons

A sink gives every other refusal of http-delivery §8.6 by its code (playlist_receipt_walk_exceeded among them). A refusal of a playlist or an object is an answer, not an error: the call succeeds and the answer says the bytes are not to be presented.

9. The C interface

include/wai.h declares it; libwai built with feature native_sink exports it, for every native target, with no codec library (cargo build --release --no-default-features --features native_sink). A session is an opaque wai_sink_t. Inputs are bytes, NUL-terminated UTF-8 strings and JSON; outputs are JSON or bytes in a wai_buffer_t the caller frees with wai_buffer_free. Every function returns a status: WAI_OK (0); WAI_ERR_INVALID_ARG (1) for a null pointer or a length that does not fit; WAI_ERR_PANIC (4), never an unwinding across the boundary; WAI_ERR_SINK_INPUT (8) for an input that does not read, wai_last_error beginning with its reason; and WAI_ERR_SINK_ENDED (9) after the session ended. A session is safe to call from any thread: each call holds its lock. WAI_SINK_ABI_VERSION is 1 in this revision; wai_sink_abi_version() returns the library’s, and a host checks it before it opens a session. A later revision adds members to the JSON it writes and functions to the interface, and does not change those of a version.

10. Conformance

• A conforming sink gives every call of the corpus the answer it states, and ends every case with the bundle it states, byte for byte; the bundle verifies under stream-audit §10 with the outcome the case states.
• The corpus holds, from fixed seeds: a signed on-demand presentation played to its end; a fragment changed in transit; a session that requires signing given none; receipts that do not hold; a live chain walked through a parent, under another key, with a parent not served and one served under another name; WAI objects held to their cids; a live revision that rebinds an alias; a stream of another service, with a key, a marked ad and a CMSD note; content addressing by the owner’s word, and names that bind nothing without it; sessions ended hidden and idle; energy entries; the log’s order and its close; a case the page’s integration of stream-audit replays call for call, signing the same bundle byte for byte; and refused calls and configurations. Every reason of §8 refuses at least one of them.
• Its second implementation, native_sink_verify.py, replays every case from this text, verifies every bundle with stream-audit’s second implementation, and catches every mutation of the corpus and every one of its checks dropped.
• A native integration’s own tests drive it through its platform’s player and require that every object the player was handed is one the sink presented, and that the bundle verifies.
• wai conform sink --suite native-sink runs the corpus against a sink, each case with its answers withheld, and writes the run’s outcome as a signed conform-result/1 record (conformance-results). WAI’s own sink is run so in CI, through the reference module and through the C interface of §9, and each record must be admitted (conformance-results §4.1).

11. Security and privacy considerations

• What verification proves. A signed playlist binds the segments it lists by URL; a name that states a content hash binds the bytes. A segment that is neither is what the origin served, and its acknowledgement says so and no more. A host that hands the player bytes a refusal withheld defeats the check, and nothing downstream can tell.
• The loopback server. A host’s server for its player listens on the loopback interface alone, on a port the platform assigns, and answers only the paths the session named, so that another application cannot fetch through it what the session fetched. Where the platform refuses unencrypted HTTP by default, the host permits it to the loopback address alone (127.0.0.1), never to a name or another address, so the exception reaches no origin.
• The session key names no viewer, device or account, as stream-audit §3.2 and §16 say; a seed is for vectors only.
• What the bundle tells. The URLs a session fetched are not in it: objects are named by their hashes, origins by their serialization, as stream-audit §7.1 has it. The observations’ cadence and the spans tell how the stream was watched; a host sends them to the owner’s collector and to no one else.