Carrier encoding turns signed protocol output into repeated media observations. In the current app path, @lss/carrier owns the real carrier format, visual/audio codecs, scan helpers, metrics, and Node MP4 workflows. @lss/embedder is still useful, but it is a smaller deterministic planning package for experiments and tests.
Current carrier package
@lss/carrier is the production-facing carrier package. It serializes carrier artifacts, encodes carrier text into visual frame chunks and audio symbols, scans those observations back from media, and reports scan metrics that @lss/web can show during reader flows.
Visual carrier
The visual carrier treats a video region as a 24 by 24 grid. Each carrier frame includes magic bits, chunk index, total chunk count, bit length, 512 data bits, and checksum bits. The app repeats those frames across scan opportunities because platform transcodes, scaling, frame interpolation, filters, and screen recording can damage individual observations.
Spatial reads encode a bit by nudging the blue channel differently on the left and right halves of a cell. Temporal reads compare the same cell across a pair of frames and decode the bit from which frame carries more blue energy. Browser scan helpers normalize candidate regions, inspect grid bits, and report scan metrics that the web reader can show to users.
Audio carrier
@lss/carrier owns the current carrier audio codecs. The marker codec writes LSSA1:<messageId>:<fragmentCount>:<checksum> using two ultrasonic bit frequencies after a preamble. The text codec packs four bits per symbol and maps each nibble to a tone in a higher-frequency FSK-style band. Scanners use tone-energy comparisons to decode marker strings or full carrier text from samples.
Audio is useful as a second observation family, but production behavior should treat it as a contributor to confidence rather than the only reliability path. Visual carrier recovery remains the primary demo path today.
Experimental embedder
@lss/embedder exposes deliberately small plans for deterministic package tests and experiments. createVisualFramePlan maps each character in fragmentData to one timed frame with four normalized luma regions near the bottom of the image. createTonePlan maps each character to one of four ultrasonic frequencies, and renderTonePlan renders those symbols into a Float32Array.
Those plans are useful for understanding budgets and for testing package behavior without the richer carrier codec. They should not be read as the current production media format.
Practical budget
The practical carrier budget is intentionally tiny. Real media paths need repeated opportunities because compression, scaling, frame interpolation, filters, and screen recording can erase or distort visual regions or tones. Pointer mode is the compact payload shape to prefer for production-style flows; manifest mode is useful when the scan result needs to carry more data directly.
Redundancy plan
Embedding should be planned like a lossy network path. A platform transcode can remove frames, a crop can hide visual regions, and a replayed screen can introduce blur or refresh artifacts. Carrier plans should therefore spend capacity on repeated fragments before they spend capacity on larger payloads.
Good carrier plans make redundancy explicit:
- Repeat each fragment across multiple frame opportunities.
- Spread adjacent fragments across time so one bad segment does not erase a whole payload range.
- Keep visual and audio channel hints in the fragment metadata so scanner and recovery code can compare evidence families.
- Prefer compact pointer payloads when the action can be resolved online.
The goal is not to make every single frame self-sufficient. The goal is to create enough independent observations that carrier scanners can recover the same signed envelope after ordinary media damage.
Package boundary
Neither @lss/embedder nor @lss/carrier should decide whether an action is allowed. They receive fragment or carrier text derived from @lss/protocol output and produce or scan media observations. Signature verification, expiry checks, issuer policy, and action policy belong before or around resolver handoff, not inside carrier code.