A Mirror That Listens to You: What I'd Check Before It Joins My Network

Somebody built a microphone that’s always on, wired it to a language model, and hung it behind a half mirror in their house. I read that sentence a few times before I read the build guide, because that’s the kind of project that makes me reach for a firewall diagram before I reach for admiration.

TL;DR: MirrorMate is a self-hosted, config-driven voice assistant: a Next.js app, SQLite for memory, wake word to trigger it, and a choice of local (Ollama, VOICEVOX, Whisper) or cloud (OpenAI) providers for the brains, the voice, and the ears. It is meant to run on something like a Raspberry Pi behind a two-way mirror. It’s a genuinely interesting piece of engineering and the kind of self-hosted project I want to see more of. It’s also a device that listens continuously, stores what it hears, and can be pointed at either your own hardware or somebody else’s API depending on a config file, which means the actual privacy story of the box in your bathroom is decided by whoever edited that file last, not by the marketing copy.

Behind the glass it is a small, sensible stack

Strip the mirror away and it’s a small, sensible stack. A Next.js app serves the interface. SQLite holds memory and session state. Speech-to-text, the LLM, and text-to-speech are each pluggable. The project’s own provider docs list Ollama or OpenAI for the language model, VOICEVOX or OpenAI for the voice, and Whisper for transcription, swapped by editing config rather than touching code. You say a wake phrase, it wakes, it listens, it answers. The target hardware is the usual smart-mirror kit: a small board like a Raspberry Pi, a one-way mirror film over a display, a mic, a speaker.

None of that is exotic. It’s the same shape as a hundred home-lab projects, a small server behind glass instead of behind a rack. What makes it worth a second look is what the stack is doing: capturing audio in a room you probably don’t lock, and retaining a memory of what it heard so it can bring it back up later.

Local-first buys you a mirror that still works with the cloud off

The pitch is that you can run the whole thing without a cloud round-trip: Ollama for inference, VOICEVOX for speech, all on-device. That’s real, and it’s the right default to build toward. But “can run local” and “does run local” are two different claims, and the gap between them is exactly one config file. The same provider system that lets you keep everything on your LAN also lets you point the LLM or the TTS at OpenAI with a couple of line changes. Nothing wrong with that as a feature, flexibility is good, but it means the privacy posture of any given install is decided by whoever set it up. I’d want to know, install by install, which providers are actually wired in before I’d trust a claim like “it’s all local.” Read the machine, don’t take the label’s word for it.

What’s the attack surface on a device built to always be listening?

This is the part that actually matters to me, and it’s really about what you’ve put on your network. A Next.js app on a fixed port is a web server, full stop, and a web server on your home LAN is a thing that needs a reason to be reachable from anywhere it’s reachable from. A wake-word listener means the mic is live continuously, not just when you think you’re talking to it. The wake-word model is doing inference on every sound in the room, all the time, by design. And a memory store that extracts and retains facts from your conversations is, functionally, a small database of things you said out loud in your house, sitting on a Pi’s SD card with whatever default permissions the setup script left it with.

None of that makes the project bad. It makes it a device I’d treat the way I treat anything else with a mic, a network stack, and a database, which is: carefully, and with a specific list of questions before it gets an IP address on the same segment as everything else I own.

What would I actually check before this went on my network?

A short list, in the order I’d work it:

• Segment it. A Pi running a web server and an always-on mic doesn’t belong on the same flat network as your laptop and your NAS. Put it on its own VLAN or a guest segment where a compromise of the mirror doesn’t hand someone a path to everything else.
• Don’t expose the port past localhost. If you need to reach the interface remotely, put it behind a reverse proxy with actual authentication in front of it, not a bare port forward. A voice assistant with an unauthenticated web UI reachable from outside your home is a Shodan search away from being a real problem.
• Treat the SQLite file like a secrets file. File permissions locked down, backups encrypted if you’re taking them, and a real answer to “what happens to this database if the SD card walks out the door.” A memory store is only as private as the disk it lives on.
• Confirm the provider config, don’t assume it. If the whole point for you is “nothing leaves the house,” open the config and read it. Verify the LLM, TTS, and STT lines actually point at Ollama, VOICEVOX, and Whisper, not at a cloud endpoint someone left in from testing.
• Decide what the wake-word model is doing with everything before the wake word. Continuous listening for a trigger phrase is standard for this class of device, but it’s worth knowing whether that pre-wake audio is discarded locally or buffered anywhere before it’s thrown away.

None of this is a reason to skip the project. It’s the reason to build it on hardware you’re willing to firewall, with a network topology that assumes it might eventually get something wrong, because eventually every internet-facing service does.

Frequently asked questions

Do I need a Raspberry Pi specifically?

The reference build targets Pi-class hardware because that’s cheap, low-power, and small enough to actually fit behind a mirror, but the software itself is just a Next.js app with pluggable providers, and it doesn’t require Pi hardware, it just fits the form factor the project is built around. Anything that can run the stack and drive a display will work; the mirror-and-Pi combination is a packaging choice, not a hard dependency.

Is my voice data actually staying in the house?

Only if you’ve confirmed the config points every provider (LLM, TTS, STT) at local services instead of a cloud API, and only for as long as you keep it that way. The project supports a fully local pipeline, but it also supports swapping any of those three components to an external API with a config change, so “local” is a setting you verify, not a guarantee that ships with the box.