Local-first path

The primary path is:

1. The Android companion discovers a nearby device over Bluetooth.
2. The phone and device perform the explicit pairing and approval flow.
3. An authenticated phone/device session carries control requests, events, and bounded transfers over the active local transport.
4. The companion presents local devices and stores local face data on the phone when no account session is active.

The firmware keeps a device-authoritative connectivity policy. Phone services default on, cloud services default off, and automatic updates default off. Connectivity can switch between Wi-Fi and BLE, with BLE treated as the nearby companion path. Available routes depend on the device configuration and services in use.

Optional cloud path

When enabled and configured, the same product can use the backend for account operations, cloud linking, synchronization, remote access, and route leasing. The backend can use Redis for short-lived mobile tickets and route leases, MQTT for Wi-Fi/device delivery, and a relay WebSocket path for phone-assisted delivery. Supabase supplies the backend’s configured auth and persistence dependencies.

These are extensions, not prerequisites for local Android/device operation. The backend’s cloud-enabled process requires its configured cloud dependencies; this page does not claim that it starts without them.

Trust boundaries and data flow

Boundary	Data crossing it	Trust assumption
Android app to device BLE	Pairing messages, signed session frames, control responses, and bounded transfers	The device approves a phone identity before granting control
Android local storage	Paired-device metadata and local face content	The phone operating system and local user account protect local state
Frontend to backend API	Account and cloud-extension requests	HTTPS, cookie/CSRF or bearer handling, configured origin policy, and backend authorization are correctly deployed
Backend to Redis	Expiring mobile tickets, route leases, replay state, and sequencing	Redis is a private configured service and is not a public trust boundary
Backend to MQTT/device path	Device payloads and route-specific delivery	Broker identity, device identity, and message verification are configured correctly
Backend relay to phone	Authenticated mobile session frames	Short-lived tickets, route leases, signatures, and replay checks work as implemented

The public model intentionally omits live hostnames, private network locations, operator topology, and deployment recovery details.