Transcribed on the phone that recorded it
Searchable, skimmable text from voice traffic. By default the phone that recorded the message writes it down, so on an encrypted channel nobody but the intended recipients can read it.
Why on-device is the default
Doing it on our servers would mean we could hear what you say. So unless your organisation chooses otherwise, the phone that recorded the message 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
- On an end-to-end encrypted channel, our servers see neither the audio nor the text
- Free, and on by default for new organisations and personal accounts
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 limitations, stated plainly
Feeding recorded audio to Android's on-device recogniser requires Android 13 or newer and an offline speech model for the language. Without them, the sending device cannot produce a transcript on its own.
- 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
- Speech recognition makes mistakes, most often with names, numbers, call signs, accents and noise. Play the recording before acting on a transcript
Shipping our own speech engine with the app would remove the Android 13 requirement without sending audio anywhere. It is on the roadmap, not in the app.