← Lumen overview
01 / Platform

One shell, one hub, a fleet behind the glass.

The device carries almost nothing. Everything it appears to do is a server-side app rendered through a hardened WebView — which is exactly what makes the whole system rewritable in seconds.

SHELL

Android thin client

A minimal Kotlin WebView APK: fingerprint unlock, mic/camera bridges, wake-lock control, and a foreground service so audio capture survives the screen turning off. That's it — no app logic on the phone.

→
EDGE

Reverse-proxied entry

A cloud edge proxy terminates TLS and forwards to the home server, so the hub is reachable anywhere without exposing the home network.

→
HUB

FastAPI plugin hub

A ~2,000-line async server: WebAuthn passkey auth, a plugin registry scanned from disk, WebSocket push to every connected screen, and versioned writes for every file change.

→
FLEET

Home-lab muscle

GPU boxes run Whisper transcription, YOLO vision, and local LLMs; a media server streams music and audiobooks; a memory service answers recall queries. Apps borrow whichever machine fits the job.

The plugin contract

Every app is a folder with three files. That constraint is the platform:

plugins/<slug>/
  plugin.json   → name, icon, tile color: how the hub renders it
  index.html    → the entire UI, self-contained
  handler.py    → optional FastAPI router, mounted at /plugins/<slug>/api/
  • Small enough for an AI to write in one pass. A complete, working app fits comfortably in a single model response — which is what makes the self-building loop possible.
  • Hot-loaded. The registry rescans on change; new tiles appear in the hub without a restart, and connected clients get a plugin_update push over WebSocket.
  • Uniform surface. Auth, sessions, push, and versioning are the hub's job; apps only bring UI and a router. Thirty-three apps share one security perimeter.

Identity and access

  • WebAuthn passkeys: the phone's fingerprint reader is the login. No passwords travel; keys are bound to the origin.
  • The shell injects a small JS bridge (screen wake, capture control) registered explicitly — the WebView is otherwise a plain browser with no implicit device access.
  • Sensitive apps (fleet control, security dashboard, host sentinel) sit behind the same biometric gate but render read-mostly views with explicit action confirmation.

Managed thin-client hardware: LumenBook

The platform extends past phones. LumenBook is a documented device-management design for thin-client laptops: an outbound-only agent that opens TLS connections to the hub, so a managed device needs no inbound route, SSH port, or LAN visibility.

  • Per-device Ed25519 identity keys; signed request envelopes with nonce, timestamp, and body hash; replay rejected.
  • Commands are short-lived, single-use grants scoped to explicit capabilities (status, wifi.connect, device.reboot, update.apply) — no default shell.
  • Signed, versioned updates with rollback protection; append-only audit trails on both ends; a local kill switch that beats every server command.
  • The design maps to NIST IR 8259A device-identity, secure-update, and device-management capabilities, and addresses the OWASP IoT Top 10 device-management gap.
Portfolio takeaway: thin-client convenience is easy; thin-client convenience with a real trust boundary is the engineering. Every layer here — passkeys, scoped bridges, capability-grant device control — exists so a rewritable system stays a governed one.

Representative request path

fingerprint → WebAuthn assertion → hub session
tile tap   → /plugins/scribe/ → index.html (UI) → /plugins/scribe/api/ (router)
           → GPU box: voice activity → Whisper → speaker clustering
           → WebSocket push: labeled transcript lines appear on the phone