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.

Channel history with a transcription line under each voice message

Why on-device is the whole point

Server-side transcription requires the server to hold your audio in the clear. That is a reasonable trade for some products; it is the opposite of what this one is for. So the sender transcribes, and the text is encrypted into the message alongside the audio.

The device already has the plaintext audio — it recorded it — so nothing new is exposed
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

A voice log where each transmission carries its transcript

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
A bundled recogniser is the roadmap answer if that version floor turns out to bite

Server-side transcription is available as an org setting for teams that want broader coverage — but it drops end-to-end encryption for affected channels, so it requires an explicit acknowledgement and is labelled in-app for everyone in the conversation.