Ariha

Overview

Ariha is a suite of fifteen voice and chat applications, built as one coordinated set so the client could compare interaction models against a shared backend rather than guess between them.

It covers real-time voice, a continuous listening mode, dedicated iOS and smartwatch clients, a shared canvas, group conversation, and a file-aware mode that calls external services through an agent layer.

The problem

The client wanted to know which voice interaction model people would actually use. Not a hypothesis, a comparison. Building one application and iterating on it would have taken a year to answer.

What I built

Fifteen related applications over four months, sharing backends so the comparison was fair: voice chat and a continuous listening variant, iOS clients for both, two smartwatch clients, a shared canvas, group conversation, file-aware chat calling external services through an agent layer, image download, history and follow-up, and the backend services behind all of them.

Complexities tackled

Knowing when the user has stopped talking. Continuous listening has no send button, so the system has to decide when a pause means “your turn” rather than “thinking”. Too sensitive and it interrupts people mid-sentence; too slow and every exchange feels sluggish. Microphone sensitivity and background noise vary enormously between a phone, a laptop and a watch, so the silence detection thresholds are tuned per device class rather than set once globally.

Browser and iOS audio. Mobile browsers restrict audio playback in ways desktop does not: autoplay is blocked without a user gesture, and playback needs an unlocked audio context. Playback was rebuilt on AudioContext rather than plain audio elements to get predictable behaviour and lower latency, with iOS-specific handling on top.

Latency is the whole product. A voice assistant that pauses noticeably between hearing you and answering feels broken regardless of answer quality. The pipeline streams between stages rather than waiting for each to complete, so recognition, inference and synthesis overlap instead of queueing. Speech recognition runs locally rather than calling a cloud API, which removes a network round trip from the critical path.

Restraint in the model layer. The assistant can search the web, and early on it did so far too eagerly, costing seconds per exchange for no benefit. The system prompt was reworked to make search the exception rather than the reflex, with explicit criteria for when it is genuinely needed.

Degrading on bad networks. Requests carry a fallback path for CORS and network failures, with error messaging aimed at the user rather than the console, because these clients run on phones and watches on unreliable connections.

Clients with no framework. The watch and iOS clients are plain HTML and JavaScript. On a watch, a framework bundle is a real cost, and there was nothing here a framework would have made easier.

Stack

Python, FastAPI, Flask, Vosk for offline speech recognition, Llama 3 through Groq for low-latency inference, gTTS for synthesis, AudioContext, Firebase for identity, nginx and Cloudflare.