PD006 · neutron design brief · stage: proposal

Neutron Desktop — the Web App, Installed

A native installer for Windows and macOS (Linux nearly free) that packages the existing web UI in a lightweight shell — the Slack model. The app ships no product logic: it points at a Neutron core, local or remote, and adds what only an installed app can — native notifications, tray presence, deep links, and a doorway to Orbit pairing.

stage · proposal decided · shell only — zero forked UI recommended · Tauri 2 (Rust) distinct from · orbit daemon (device capability)

1 · Shape

flowchart LR
  subgraph APP [neutron desktop app]
    SH[shell · Tauri 2
WebView2 / WKWebView] --> WV[web UI
loaded from the core]
    SH --> N[native notifications · tray ·
badge · deep links neutron://]
  end
  WV -->|https + cookies| C1[remote core
SaaS instance]
  WV -->|http localhost| C2[local core
docker-compose / own pod]
  SH -.->|later· pair / detect| OB[orbit daemon
exec-gate · screen · fleet]

The web app is the app. The shell loads the UI straight from the configured core, so every product update ships to desktop users on deploy — no app-store release train for features, only for the shell itself.
Core switcher. First-run asks for an instance URL (or discovers a local core); multiple cores can be saved and switched, matching the swarm topology — one on the Mac, one on the server.
Auth unchanged. OIDC in the webview with __Host- cookies, exactly as the browser; the shell stores no credentials.

2 · Why Tauri, not Electron

Criterion	Tauri 2	Electron
binary weight	~10 MB, system webview	150–250 MB bundled Chromium
stack fit	Rust — same as orbit + assay	Node runtime
orbit pairing later	shared Rust crates possible	IPC bridge only
maturity of tray/updater/deeplinks	first-class in v2	mature

Cost of the system-webview choice: WebView2 (Chromium) on Windows vs WKWebView (Safari) on macOS means the UI must stay Safari-clean — it already must be, since Mac browsers are a first-class client today.

3 · Orbit relationship — deliberately separate

Desktop app = where a human uses Neutron. UI shell, no device authority.
Orbit daemon = what Neutron may do to a machine. Exec-gate, screen vision, fleet, anti-theft — its own install, its own consent ceremony.
Keeping them separate keeps the trust story clean: installing the chat app never implicitly grants machine control. The app may later detect a local orbit daemon and offer pairing — through the existing pairing flow, never around it.

4 · Phases

Shell (~4–6 sessions). Tauri project, core URL config + switcher, session persistence, native notifications from the existing realtime events, macOS + Windows CI builds. macOS signing/notarization reuses the orbit codesign pipeline.
Installed feel (~3–5 sessions). Tray + unread badge, deep links (neutron://thread/… from emails and forge comments), auto-update channel, Linux AppImage.
Orbit doorway (~2–3 sessions). Detect local daemon, surface pairing status, hand off to the existing orbit pairing flow.

5 · Acceptance

Fresh install → enter instance URL → logged in via OIDC → chat, approvals, canvas all work with zero UI forks.
A gated approval raises a native notification; clicking lands on the approval card.
Same build connects to a localhost core and a remote SaaS core, switchable.
Signed + notarized macOS build; signed Windows build; auto-update verified.
Installing the app grants no machine capability — orbit pairing remains an explicit, separate consent.