Real-time, no refreshing

Talking to an assistant is like holding a thread. If every sentence started from scratch, the conversation would lose its immediate memory and rhythm. Here's why we chose an always-open channel.

A conversation isn't a series of requests

Classic web architecture relies on isolated requests: you ask, you receive, you hang up. That's perfect for loading a page, but unsuitable for a living exchange. A conversation has continuity: what you just said colors the next response, the assistant can speak in multiple stages, audio arrives in fragments. Treating each sentence as an independent form would have broken this natural flow.

An open channel

So, we built the exchange on a WebSocket: a single connection, open for the duration of the session, through which messages flow in both directions. The client sends audio, the server sends back text and voice, without re-establishing the connection each time. Authentication happens at the opening, via a token transmitted during the handshake. After that, the tunnel is established, and everything passes through it.

Audio as a stream

This channel allows voice to be processed as a stream rather than a file. The response can start playing while it's still being generated, and the server knows how to adapt: if the user has muted the sound, it simply doesn't send the speech synthesis, saving unnecessary computation. The same pipe serves everything, which is what makes the exchange fluid rather than choppy.

Staying alive despite the network

An open channel has a vulnerability: the network can cut it off. A tunnel interruption doesn't make the memory or the ongoing conversation disappear; upon reconnection, the thread picks up where it left off. On mobile, where you switch from Wi-Fi to 4G while walking, this resilience isn't a minor detail: it's the condition for a voice assistant to remain a constant companion.