Feature request: native voice input (speech-to-text) in the Web UI

[tigerwho1888]

What

Add a built-in voice input (speech-to-text dictation) option to the DSH Web UI — a microphone button in the chat composer that transcribes speech into the input draft for review before sending, while the model you selected still executes the request.

Why

• Voice is much faster than typing for long or multi-part prompts, and enables hands-free use (walking, driving, accessibility).
• Several community plugins already implement pieces of this, which shows real demand:
  • dsh-plugin-voice-input
  • dsh-voice-input-plugin
  • dsh-voice-chat
  • dsh-speech-plugin
• A first-party implementation would standardize UX, security, and maintenance across the ecosystem.

Suggested scope

• Mic button in the composer tool row; record/stop; transcription streams into the draft (opt-in live captions).
• Pluggable STT providers — local Whisper (whisper.cpp) and OpenAI-compatible ASR endpoints — with priority failover, mirroring the existing plugin-based architecture.
• STT stays a pure "dictation" layer: it only fills the draft; the user reviews and edits, then the selected model executes the request.
• Privacy: API keys stay server-side (environment / credentials seam), audio is not persisted by default, and transcripts never go to the main model.
• Nice-to-have companion: optional TTS read-aloud of final assistant replies.

Thanks for considering it!

[Jstn-1g]

This request identifies the boundary I would standardize first: voice input should produce an editable draft, never a submitted model turn.

I have been maintaining DSH Live Voice as a deliberately bounded community prototype for that contract. Against exact dsh-v0.1.2-alpha.1, it currently exercises the existing dsh.client browser bundle, conversation.input.left / conversation.input.dock slots, public Session lifecycle, Host-only credential resolution, and the authenticated Web upgrade seam. The prototype requires destination/Session disclosure plus a separate recording gesture, exports no Harness history/files/tools/instructions, keeps assistant output preview-only, and permits only a completed final user transcript to become an editable composer draft through an explicit action that does not submit.

The useful failure cases have been Session switching and BFCache restoration: capture, playback, provider work, sockets, timers, buffers, consent, and composer authority all need deterministic teardown or fresh binding. The current preview has exact regressions for those paths. That evidence used synthetic Web Audio and a fake loopback provider; it is not physical-device, live-provider, or packaged-Desktop proof.

From that implementation, I think a stable first-party surface should be provider-neutral rather than Qwen-specific:

1. a Host-owned STT provider contract with a credential schema, declared formats/capabilities, cancellation, and strict byte/time/queue bounds;
2. an exact-Session client binding and a supported way to promote only a finalized user transcript into the current editable draft, never auto-submit;
3. lifecycle semantics for Session replacement, disposal, pagehide/BFCache, provider failure, and permission denial;
4. explicit non-persistence by default, with no transcript reaching the selected model until the user reviews and submits it; and
5. a transport abstraction that works for both served Web and packaged file:// + IPC clients.

The current public seams cover placement and served-Web composition well. The remaining architecture gap is the last item: plugins can authenticate an HTTP(S) upgrade, while the documented packaged IPC transport has no public arbitrary bounded binary-duplex face. I recorded the alternatives and acceptance criteria in Live Voice issue #20; a measured Remote/Gateway carrier should be tried before proposing a new duplex API.

Would maintainers prefer a standardized STT plugin/service contract that community providers implement, or a core-owned dictation adapter with provider plugins beneath it? I can contribute the existing safety/lifecycle test matrix and adapt the prototype once the intended public seam is clear. I would keep optional TTS separate from the first dictation contract so microphone-to-draft can land without inheriting playback and full-duplex complexity.

[Jstn-1g]

Concrete follow-up on the draft-before-send contract in this request: DSH Live Voice Preview.5 now includes a two-minute, zero-credential synthetic path. It opens the disclosure in a live DSH Web Session, runs one fixed local turn, returns fixed transcripts plus a deterministic chime, and lets the user place only the synthetic user transcript into the current draft through an explicit action. It never submits the composer.

This path does not request microphone permission, resolve a Qwen credential, or contact an external provider. It is deliberately not proof of native speech-to-text, a physical microphone or speaker, live Qwen, BFCache, packaged Desktop, or first-party inclusion.

If you use Windows with Chrome or Edge and are willing to test this exact interaction in a disposable Web profile, issue #58 asks for one narrow result: the last setup stage reached and where you stopped. Please do not share recordings, credentials, real transcripts, Session IDs, tokens, cookies, workspace content, personal data, or identifying logs. Passing and stopping-point reports are both useful.