How going off the record is supposed to work

A call in this system is always in one of a few modes, and the mode is not a setting on your machine — it is a fact everyone on the call has agreed to. An ordinary live call is the plain case. A call can be put into a recording mode. And a call can be taken off the record, which is the mode this piece is about.

Switching modes is a small ceremony. One participant proposes the change, and every other participant has to sign it — sign in the cryptographic sense: each person's device produces a short proof, tied to their identity, that only their device could have produced. The collected signatures travel together as one event, and that event is appended to the shared record the call is bound to: an append-only log that every participant replicates, so nobody holds a private version of what was agreed. Once the switch lands there, both sides can see it and neither side can quietly deny it later.

What that agreement is supposed to buy you is enforcement at the narrowest place it can be enforced: the individual frame. Audio and video are captured by two separate recorder taps — small pieces of code that sit on the media path and are handed each chunk of sound or picture as it goes by, deciding whether it may be written down. Each tap asks the same questions of every frame, in order:

flowchart TD
  F["a frame arrives at the recorder"] --> X{"is this frame's call
the one we registered for?"}
  X -- no --> R1["refuse — cross-call leak guard"]
  X -- yes --> M{"what mode is this call in,
read fresh for this frame?"}
  M -- "off the record" --> R2["refuse — and say so by name"]
  M -- "ordinary live call
(the DEFAULT, including
a call never seen before)" --> C{"was recording consent
granted and not revoked?"}
  M -- "recording" --> C
  C -- no --> R3["refuse — consent guard"]
  C -- yes --> A["admit the frame"]

The mode is re-read per frame, not read once when the call starts. That is the whole point: a switch made in the middle of a conversation has to take effect on the next frame, not on the next call. And when a frame is refused, the refusal names the rule that refused it, so "not recorded" and "not recorded because the call is off the record" are distinguishable — which matters more than it sounds, and comes back below.

Audio and video bind their own copy of this check independently, and live captions bind a third. That is by construction rather than by care: each listener registers separately and carries its own guard, so the three paths cannot accidentally share one.

The default, and why it is not what you would hope

A call whose mode has never been observed reads as an ordinary live call, and an ordinary live call permits the recorder. The mode guard refuses on exactly one value: the explicit off-the-record state. It is a stop-gate, not a start-gate.

Nothing in this mechanism is what stops an ordinary call from being recorded. That is a separate ceremony — recording consent, which someone has to grant before a recorder starts at all, and can revoke afterwards. So the honest reading of the mode guard is narrow: a call that was being recorded and is then taken off the record stops. It is not "recording is off by default because of this check."

And what happens when things go wrong

The current mode is held in memory by the program running on your machine, as a cache of what the shared record says. A restart mid-call therefore comes back remembering nothing, the call reads as an ordinary live call, and the off-the-record refusal quietly lifts on that machine. The shared record itself is unaffected — it still carries the signed transition, and peers replicating it still see it — but this machine's recorder would fail open between the restart and the next mode change.

The designed answer to that is a replay step: at startup, the signed events are re-read in order and the in-memory picture is rebuilt from them, so the machine recovers the mode it should have been in. That step is shipped and registered, and it is deliberately marked non-critical — meaning an event whose contents cannot be read is skipped rather than aborting the whole replay. The trade is explicit: the record still lands, and only this machine's local view lags until the next readable mode change corrects it.

Ending a call forgets the entry on purpose, returning that call to the default.

Finally, the check on a mode change is structural: it enforces that every participant appears with a well-formed signature. It does not itself verify those signature bytes against each participant's key — that belongs to the verifier further out, and the code says so where the check is defined.

What was wrong

A call had been switched off the record. The signed record said off the record. The recorder kept writing.

That is the whole defect, and it survived for months in a system where every other part of the story was correct. The switch was real, the signatures were real, the event landed on the shared record, and both sides observed it. The check that answers "may the recorder have this frame?" was real too, and correctly written. The two had simply never been introduced.

There were two versions of the mode check sitting in the calling code — one that throws, one that returns true or false. Both were correct. Both had zero callers in the shipping code, and every reference to them was prose, including a line in the calling code's own design note naming the throwing one as the gate. Meanwhile the state machine did derive a "stop recording and delete" effect when a call went off the record, and that effect had exactly two consumers. Both were log lines. One of them logs the word "dispatched" while dispatching nothing.

So frames arrived at a check that asked about consent and never about mode. Consent had been granted, back when the call was on the record. Nobody had revoked it. The check answered truthfully and let the frame through, and the bytes kept accruing behind a label saying they were not being kept.

How it was fixed — and what is still not fixed

Both recorders now ask, per frame, whether the call is currently off the record, and refuse with a reason naming the mode if it is. One lookup and one string comparison — cheap enough to sit on the path every frame takes.

Two details are worth more than the fix itself.

Both recorders, or neither. Gating only the audio path would have left video recording frames in an off-the-record call — and a test written from the design note's sentence ("the recorder refuses frames while off the record", no medium named) would still have passed. So the change was verified by deliberately removing only the video half: exactly the two video assertions go red, and the six audio and caption assertions stay green. Each half is independently load-bearing, so a half-fix cannot ship green.

The test had to assert the reason, not the refusal. Before the fix, the check already returned not allowed for the scenario under test — for an unrelated reason, because the listener was not registered. A test asserting only "the frame was refused" would have been green before the fix and green after it, and would have proved nothing at all. The assertions had to be on which rule refused. That is the difference between a test that passes and a test that can fail. The captions path being unaffected is pinned by a test now too, because "unaffected by construction" is a claim that quietly stops being true.

Three limits we are not going to bury

What was already captured is not deleted. The effect that says to stop and delete is still consumed by two log lines and nothing else — we re-checked that on the current shipping code, rather than trusting the commit note. Going off the record stops new frames; it does not yet remove the old ones.

No in-call control sends the switch. The request that changes a call's mode is registered and routable, but nothing in the call window or the phone clients sends it. We checked with an instrument we first confirmed can see the requests that button does send. So today this is a capability reachable programmatically, not a button.

The signature check is structural, as described above: well-formed signatures from every participant, but not a verification of those signature bytes against each participant's key.

And the repair itself was proven by tracing the code and by tests, not by a live call. The author's own note records that no runtime reproduction of frames landing on a real off-the-record call was performed.

Why we are publishing a fix rather than a feature

Calls are not finished here. This work sits inside a calling feature that is mid-implementation, and whose earlier declaration of completion was retracted in April with an unusually blunt reason left on the record: the gate passed on document contracts rather than on a verified, user-visible call across two machines. This defect is exactly the shape that reason predicted. A sentence said a gate protected recording. The sentence was true about the gate's existence and false about its effect, and nothing in the build could tell the difference, because there is no rule that fails when a correct function has no callers.

That is the transferable part. A safety property named in a document, implemented correctly, and never invoked is worse than an absent one — an absent guard makes people nervous, and a documented one makes them relax. The useful question is never "does the check exist?" It is "what calls it, and what happens on the frame where nothing does?"

Related: Recording a call with consent you can revoke · Consent you cannot forge · Browser-to-browser calls with no server in the middle.

Written by AI agents from real project logs; owned and edited by Mujo.

Written by AI agents from real project logs; owned and edited by Mujo.