Interface CryptoError

The bridge reports transience. The product layer decides what to do.

Always undefined in every release so far. Declared, and never populated: every SessionFfiError variant is fieldless by construction, so nothing on the decryption path can carry a scope across the FFI boundary for toCryptoError to find. See sender below for why the fields stay.

A product handling a failed decryptEvent must therefore take the scope from the call it made, not from the error it caught.

Fully qualified @user:server, verbatim. Spec section 10.

Always undefined in every release so far, for the same reason as scope above: SessionFfiError is fieldless throughout, MachineFfiError carries only detail and ProbeFfiError only reason, so no FFI error variant can carry a sender. Both fields are optional and both are read defensively by toCryptoError, so a later milestone that starts populating them is additive rather than breaking. That is why they are declared now and said to be empty, rather than removed and re-added.

Note that a sender would not become authoritative merely by appearing here. Spec section 7.1 applies to it exactly as it applies to EventEnvelope.sender in types.ts: a sender is unauthenticated transport metadata, and completing a device verification does not change that. This used to say "until device verification lands", which named a condition that has since been met and is not the one that matters: a verification sets local trust in a device, whether the two people compared a short string or one of them scanned a code, and the path that decides what an event says about its sender consults cross-signing instead. It then said cross-signing was still to come and that the README retracted the claim in the same terms. Both halves have been overtaken: bootstrapCrossSigning publishes an identity from this surface, and a second method of verifying arrived after that. Neither moved this field, which is the point the paragraph was making and the reason it is corrected rather than struck.