LSSP/1 is the current protocol envelope. It carries a signed action payload through one or more carrier channels and lets the reader reconstruct enough observations for the caller to verify and resolve an action.
Payload
An LSSP payload contains the action name, body, issue time, expiry, nonce, issuer ID, payload ID, mode, and version. The signed envelope adds signature and signatureAlg. The current package uses Ed25519 because the signatures are compact and fast to verify.
Packet shape
LSS uses the same basic discipline as internet packet layers: keep a small header near every unit of transmitted data, make each unit independently identifiable, and let the receiver reassemble the original message from packets that may arrive out of order, duplicated, or partially damaged.
The current protocol fragment is closer to an IP packet than to an application JSON blob. The carrier may be a video frame, an audio symbol window, or a simulated detector result, but the protocol packet has the same job in each case. The fragment header is deliberately smaller than the signed payload. Issuer, payload mode, action body, issued time, expiry, nonce, and payloadId live inside the signed payload bytes; fragments carry the metadata needed to move and reassemble those bytes.
CURRENT TYPE SHAPE
| Field | Purpose |
|---|---|
protocol | Identifies the fragment protocol. Current value is LSSP/1. Carrier frames may have their own lower-level magic. |
messageId | Groups fragments that belong to the same serialized signed envelope. |
fragmentIndex | The position of this fragment in the reassembled byte stream. |
fragmentCount | The number of data fragments expected for the payload. |
parityIndex | null for ordinary data fragments, 0 for the current XOR parity fragment. |
channelHint | The intended carrier family: audio, visual, or any. Candidate observations also record their actual source. |
checksum | FNV-1a 32-bit hex checksum over messageId, fragmentIndex, fragmentCount, parity marker, and decoded data bytes. |
data | Base64url-encoded bytes for this fragment. For data fragments this is a slice of the serialized signed envelope; for parity fragments this is XOR recovery data. |
The IP diagram analogy is useful because the receiver should not need a perfect single observation. It should be able to say: this fragment is LSSP/1, it belongs to message X, it is fragment i of n, its checksum passes, and its data can contribute to signed-envelope reconstruction. Only after reassembly does the caller parse and verify signed-payload fields such as issuerId, payloadId, mode, issuedAt, and expiresAt.
Fragmentation
Fragments carry protocol metadata, message identity, fragment indexes, optional parity metadata, a channel hint, checksum, and base64url data. @lss/protocol owns this layer so @lss/embedder and @lss/reader can stay focused on carrier behavior.
Fragmentation matters because video and audio carriers have small reliable budgets. A signed envelope may be larger than one carrier frame, so LSS splits it into fragments and repeats those fragments across time. The reader does not trust arrival order. It groups fragments by messageId, keeps the highest-confidence candidate for each fragmentIndex and parityIndex, and reconstructs only when enough indexes have passed checksum checks.
Redundancy
Network layers assume loss; LSS should assume media loss. Compression, cropping, motion blur, exposure shifts, platform transcodes, screen recording, and speaker or microphone limits can erase parts of the carrier. Redundancy is how the protocol stays usable when some observations disappear.
LSS handles redundancy at three levels:
- Carrier repetition: the embedder can place the same fragment in multiple frames or audio windows so the reader gets repeated chances.
- Cross-channel evidence: visual and audio observations can support the same
messageIdeven when one channel is weaker. - Parity fragments:
fragmentBytesadds one XOR parity fragment by default when there is more than one data fragment. The recovery pool can use that parity fragment to recover exactly one missing data fragment.
The reader should report redundancy as evidence, not magic. A high-quality scan might show repeated observations for every index, zero checksum failures, and agreement across channels. A weak scan might show missing indexes, conflicting candidates, or parity recovery being required.
Reassembly and expiry
Reassembly is intentionally stricter than detection. Detecting visual regions or tones only proves that an observation might contain LSS data. Reassembly has to prove that enough valid fragments belong to the same message, pass checksum, fit the declared fragment count, and produce signed-envelope bytes that the caller can parse and verify.
Expiry plays a role similar to time-to-live. LSS packets do not hop across routers, but they do travel through shares, reposts, downloads, projections, and screen recordings. expiresAt limits how long a captured action should remain resolvable. The protocol carries this field, but the current resolver package does not enforce it; callers must reject expired payloads before running product behavior.
Trust boundary
The application boundary is the trust boundary. @lss/reader can reconstruct bytes, @lss/protocol can verify the Ed25519 signature with an issuer public key, and @lss/resolver can map an already-verified payload to a demo action result. Expiry checks, issuer policy, replay prevention, and revocation are caller responsibilities today.
Failure posture
Readers should surface uncertainty instead of silently accepting weak observations. A payload can fail because fragments are missing, fragment checksums disagree, the signature is invalid, the expiry has passed, or the action body is unsupported by the resolver.