Blog

How Baby Monitor Timmy Works Technically

WebRTC, Firebase, and end-to-end protection, explained without buzzword fog.

By Baby Monitor Timmy · April 2025 (updated July 2025)

Three Building Blocks, One Goal

Under the hood, Timmy is built in a pretty pragmatic way: Flutter for the app, WebRTC for real-time audio and video, and Firebase for coordination. I did not want to build a huge platform that pushes everything through the cloud. Each part should know as little as possible and still work reliably with the others.

WebRTC: Direct Connection, Encrypted by Default

WebRTC (Web Real-Time Communication) carries audio and video between the baby and parent devices. In the best case, the data flows directly between the two devices, peer-to-peer, with no media server in between.

Every WebRTC connection uses DTLS-SRTP by default. If someone captures network packets, they do not get readable audio or video. This encryption is part of the protocol and cannot just be switched off in WebRTC.

That was the important point for me: nursery media does not belong on my server. It stays between your devices.

Signaling via Firebase Firestore

Before WebRTC can start, the devices need to find each other and negotiate how they can connect. That part is called signaling. Timmy uses Firebase Firestore, Google's cloud database, for it.

Only technical connection data is exchanged:

Audio and video do not land in Firebase. Firestore only transports the technical connection data. Timmy also encrypts this signaling layer, so Firestore does not become a cleartext meeting point for SDP and ICE.

TURN Servers: When the Direct Path Doesn't Work

Some networks block direct connections, for example strict firewalls or certain mobile carriers. Then WebRTC needs a TURN relay (Traversal Using Relays around NAT).

Timmy tries the local TURN server first and uses Cloudflare as fallback when the local relay is unavailable or overloaded. The relay forwards encrypted packets. It does not get keys for sound or video; WebRTC encryption remains intact.

TURN credentials come from a Firebase Cloud Function and are valid for only 24 hours. Permanent credentials in a baby monitor app would be too risky for my taste.

Nearby Connections: Devices Find Each Other Automatically

To avoid awkward setup steps between the baby and parent device, Timmy uses Nearby Connections. Google provides this discovery layer over Bluetooth and WiFi.

Automatic pairing in Timmy works without manual code entry: the devices discover each other and find the same meeting point for the key exchange. If that fails, there is a 4-character code you can type in. The pairing code never leaves the device; Firestore only sees a cryptographic hash (SHA-256) as the document identifier.

Anonymous Authentication

Timmy uses Firebase Anonymous Authentication. On first launch, each device receives a temporary, anonymous ID. There is no account, no email address, and no password. The ID is only there to enforce Firestore rules: only authenticated devices may read or write session data.

The Architecture: Who Sends, Who Receives

Timmy has two modes:

Controls such as push-to-talk and camera on/off use a DataChannel, another WebRTC channel that sends small encrypted messages directly between devices.

Why Flutter?

Flutter is Google's framework for apps on multiple platforms. For Timmy, that means I can write a lot of logic once and use it on Android and iOS. Timmy is available on Android, and the iOS version is close to release. Less duplicate code means fewer places where bugs can creep in.

Summary

The technical rule is simple: Timmy should only touch the data it truly needs. WebRTC protects the media, Firebase coordinates connection setup, TURN sees only encrypted packets, and Nearby Connections takes friction out of pairing.

Good technology disappears into daily life a little. It works without turning the nursery into a cloud project.


More Articles