Client And OS-Level Roadmap
Prox OS is web-first today. The current product is a browser shell with app
Prox OS is web-first today. The current product is a browser shell with app registry, windows, Spaces, Switchbar, Proxied Spaces, and Desktop Surface Engine renderers.
This document describes long-term client routes. It is a roadmap, not a shipped implementation contract.
Current Stage: Browser Shell
The browser shell can render OS-like windows, route local and package apps, host iframe apps, show Proxied Spaces, and switch desktop layout modes.
Limits:
- no system-level link interception;
- no desktop tray;
- no OS global shortcuts outside the browser tab;
- no real cookie/profile isolation for third-party websites;
- no local file indexer beyond browser-safe APIs.
Web/PWA-first remains the default for v0.1. A native or local companion
should appear later only when real use cases require local file access, local
LLMs, background automation, notifications, or a local MCP gateway.
PWA Stage
A PWA can make Prox OS feel more installable and durable:
- app icon and standalone launch;
- stronger offline shell assets;
- improved mobile/tablet entry;
- Mobile Launchpad as a high-frequency pocket entry for capture, AI, notifications, approvals, and dynamic view previews;
- possible background sync within browser limits.
It still cannot promise desktop-client-level session isolation or system link capture.
Mobile PWA should validate Device Studio before any native app starts. See Device Studio and PWA Positioning.
Device Studio Companion Path
Device Studio is a client direction, not a separate platform. It should sequence through:
- responsive mobile web;
- Mobile Launchpad PWA;
- declarative Studio View JSON renderer;
- Studio Gallery / Templates / Verified Views;
- Expo-based native companion app only after native capability needs are validated.
The native companion must not become a full Prox OS runtime, arbitrary code host, or unreviewed mobile app marketplace. Dynamic mobile UI should be contract-driven and render trusted blocks. See Studio View JSON and Native Companion Expo Boundary.
Browser Extension Helper
A permissioned browser extension helper could improve:
- explicit link capture from normal browsing;
- user-submitted URL metadata;
- tab-to-Prox handoff;
- contextual save-to-Space actions.
It should remain user-controlled and avoid silently intercepting sensitive browsing data.
Tauri / Electron Desktop Client
A desktop client or local companion could unlock stronger local affordances:
- system tray;
- global shortcuts;
- system-level link interception;
- local file indexing;
- desktop notifications;
- profile or cookie isolation investigation;
- local helper processes for approved workflows.
- local LLM provider adapters such as Ollama, LM Studio, or other local model runtimes;
- local vault storage using filesystem, IndexedDB, OPFS, SQLite WASM, or a native helper;
- local UI generation from private datasets into personal dashboards, Spaces, and agent views;
- browser, file, and scheduled-task automation with explicit permissions;
- local MCP gateway access to trusted tools and services.
Cookie/profile isolation is an investigation for a desktop client, not a promise of the browser shell.
Local Runtime Capability Map
| Capability | Web/PWA v0.1 | Local companion later | Why it matters | Risk |
|---|---|---|---|---|
| Local LLM | Provider abstraction only. | Ollama, LM Studio, or local model adapter. | Privacy and cost control. | Model quality, UX, and support burden. |
| Local data vault | IndexedDB/export basics. | Filesystem, SQLite, OPFS, or native helper vault. | Data sovereignty and private data workflows. | Backup, encryption, and recovery complexity. |
| Local UI from data | Templates and mock views. | Generate local dashboards from local datasets. | Personal OS value over private data. | Security, performance, and hallucinated schemas. |
| Local automation | Manual actions only. | Browser, file, notification, and scheduled-task automation. | Real agent usefulness. | Dangerous permissions and ambient authority. |
| Local MCP gateway | Docs only. | Connect local tools and services through scoped MCP. | Extensible agent runtime. | Credential leakage and unsafe tool execution. |
| Developer workflow | GitHub-first docs and app manifests. | Local CLI, manifest validation, template preview, and GitHub submission. | Avoid building an expensive online IDE too early. | CLI fragmentation and support load. |
Local Security Rules
- No ambient authority. Local tools must require scoped prompts and visible grants.
- Store credentials in scoped stores, not general app state.
- Show permission previews before dangerous operations.
- Emit audit logs for reads, writes, executions, and revocations.
- Provide revocation and cleanup paths.
- Keep local companion selection open: Tauri, Electron, Docker gateway, and native helper process are candidates, not final decisions.
OS-Level / Appliance Imagination
Long term, Prox OS can explore ChromeOS-like, Linux shell, kiosk, or Prox OS Flex-style deployments. That would be a platform distribution project, not a frontend task.
The current codebase should keep clean contracts so this direction remains possible, but it should not pretend a browser app is already a hardware OS.