Transcribed on the phone that recorded it
Searchable, skimmable text from voice traffic — without anyone but the intended recipients ever being able to read it.
Why on-device is the whole point
Doing it on our servers would mean we could hear everything you say. That is a fair trade for some products; it is the opposite of what this one is for. So the phone that recorded it writes it down, and the text is locked away with the audio.
- The phone already has the recording — it made it — so writing it down there gives nothing away
- Recipients decrypt and read; they never run speech recognition themselves
- Our servers see neither the audio nor the text
Read when you cannot listen
A transcript makes voice usable in the situations where audio is not: a loud yard, a quiet ward, a meeting, or a backlog of forty messages you need to triage rather than hear.
- Every history row carries a transcription line as a permanent slot
- Scan a channel in seconds instead of replaying it in real time
- Transcripts are archived with the message, so the Vault is searchable rather than a pile of audio
The limitation, stated plainly
Feeding recorded audio to Android's on-device recogniser requires Android 13 or newer. Below that, the sending device cannot produce a transcript.
- Only the sender needs Android 13+; recipients on any version get the transcript for free
- Where a sender cannot transcribe, the row says so rather than showing a blank line
- If that turns out to matter to you, shipping our own speech engine with the app is the fix, and it is on the roadmap
There is no server-side option, and the setting for one is refused if you try — it would mean handing us your audio, and we are not going to offer that quietly. Writing it down on the phone is the only way this works today.