Focus review on the security-critical building blocks
A separate core makes it obvious which parts actually matter for privacy and security instead of hiding that logic inside the full product.
Security Core
The Security Core Behind Timmy
Timmy should not ask for trust through branding alone. Pairing, signaling, and backend boundaries therefore live in a separate public core that can be reviewed directly.
- Publicly reviewable pairing and signaling building blocks
- Clear separation between security-critical logic and product UI
- Direct links into the parent-facing guides
What you can review here
The architecture, not just the promise
1
Inspect pairing logic
The core isolates ECDH pairing, key derivation, and document boundaries so security assumptions do not hide inside UI code.
2
See signaling boundaries
Firestore and backend contracts are documented where they matter most for privacy and review, instead of being buried in app orchestration.
3
Connect the core to real parent questions
If you care more about the everyday meaning than the repository structure, the guide hub continues with privacy, pairing, and permissions.
Read next
For the parent-facing explanation of the same topics, continue in the guide hub with secure pairing, privacy, and app permissions.
Pairing
Signaling
Backend boundaries
publicly reviewable
This page is the technical sister to the guide hub. The guides explain why parents should care about pairing, privacy, and network architecture. The security core shows where those questions land in the system itself.
That keeps the same reading rhythm as the redesigned guides: orientation first, then clear review areas, and only then repository depth.
Why separate it?
Because trust depends on a few critical places
Not every line in a baby monitor matters equally. The decisive parts are the ones that pair devices, move signaling through backend paths, and define which data can ever reach a server.
Keep UI and security logic distinct
The product surface can evolve without blurring the boundaries that should stay easy to inspect and reason about.
Make the architecture easier to understand
A public core forces clearer contracts and documentation that remains readable even outside the full app context.
What lives in the core?
The pieces every session depends on indirectly
The core contains the parts that determine whether a session is trustworthy, not the entire product stack.
Firestore and backend boundaries
Document structure, allowed fields, and cleanup behavior belong in the reviewable core because they define data exposure.
Contracts between client and server
Signaling is not invisible plumbing; it is a defined contract with privacy and security consequences.
ECDH pairing and key derivation
How a short code becomes real security is one of the central trust questions in an auditable baby monitor system.
Documentation as a public artifact
The core is not just code. It is also the architectural explanation that makes review and discussion possible.
Repository & guides
From public core to parent perspective
Technical review paths and parent questions belong together. That is why this page links the repository directly to the matching guide topics.
Public Git repository
baby-monitor-timmy-core is open for review
The repository contains the separated security-relevant building blocks: pairing, signaling, backend boundaries, and the security-architecture documentation. The app UI remains separate so the part that matters most for trust can be reviewed directly.
Open the GitHub repository →Secure baby monitor pairing
The parent-facing explanation of why a short code alone is not enough and what stronger pairing should look like.
Read guide →Privacy in baby monitor apps
The right next step if you want to turn architecture questions into practical criteria about data flow, storage, and third parties.
Read guide →See Timmy in the real product flow
From the security core back to the product surface: the homepage demo shows how this architecture becomes an everyday experience.
See the interactive demo →