feat: durable recorded voice-note messages

[nickgiulioni1]

Feature request: durable recorded voice-note messages

Motivation

Buzz has active work for dictation, message read-aloud, huddle speech models, and shared-compute model routing, but it does not appear to have a native way for one person to record and send the original audio as a durable message.

This is distinct from:

• dictation, which converts speech into composer text;
• message read-aloud, which synthesizes speech from an existing text message;
• huddles, which are live sessions rather than durable asynchronous messages; and
• automatic transcription, which should be an optional later layer rather than the message itself.

Recorded voice notes are useful when someone can speak more naturally or safely than they can type, especially on mobile. The recipient should be able to receive and replay the original recording after either client restarts.

Proposed solution

Add a first-class recorded-audio message flow:

1. Record from the message composer using an accessible tap-to-record control (with press-and-hold considered only if it has an equivalent non-gesture path).
2. Show elapsed time and clear recording state while capturing.
3. Let the sender preview, re-record, cancel, or send.
4. Upload the audio through Buzz's existing attachment/media path and publish a durable message that references it with enough metadata to render consistently (media type, duration, byte size, and attachment identity/integrity fields already used by Buzz where applicable).
5. Render an inline player for recipients with play/pause, elapsed/remaining time, seek support where feasible, download behavior consistent with other attachments, and accessible names/state.
6. Preserve the recording and playback state across normal app restart/reload. Apply existing message deletion and channel/DM authorization rules rather than inventing a separate permission model.

Suggested MVP boundaries:

• original audio is the canonical payload;
• no automatic transcription;
• no voice cloning or generated speech;
• explicit duration and upload-size limits, with validation before upload and at the receiving boundary;
• one supported interoperable encoding/container chosen with maintainer input;
• desktop and mobile may land incrementally, but the protocol/attachment shape should not be client-specific.

Before implementation, maintainer guidance would be especially valuable on whether this should use the existing attachment event/message shape unchanged or needs a small typed audio extension.

Alternatives considered

• Send an ordinary audio file attachment. This may carry the bytes, but it does not provide the composer recording flow, duration-aware inline player, recording limits, or consistent accessibility expected from a voice note.
• Reuse dictation. Dictation discards the original delivery medium and changes the sender's intent into text.
• Reuse huddles. Huddles are synchronous and do not model a durable per-message recording.
• Bundle transcription into v1. This adds privacy, compute, language-quality, and failure-state complexity. It can be layered onto the durable audio message later, explicitly and opt-in.

Acceptance criteria for an initial contribution

• Two Buzz users can record, preview, send, receive, and play a voice note.
• The recipient can still play it after both clients restart.
• A failed/cancelled recording or upload does not publish a broken message.
• Duration/size limits are enforced and surfaced clearly.
• Keyboard and screen-reader users can operate every recording and playback action without relying on a press-and-hold gesture.
• Tests cover recording state, cancellation/failure, attachment serialization/parsing, and playback state; the PR includes a short demo recording.

Additional context

Closest active work found:

• PR #3240 — per-message read-aloud
• PR #3759 — local voice dictation
• PR #3257 — streaming Pocket TTS
• Issue #3720 — pluggable STT/TTS backends
• Issue #3410 — external models through shared compute

None of those is a durable recorded-audio message. Exact GitHub issue/PR searches for “voice note” and “voice message” found no matching owner as of 2026-08-01.