Windows Desktop App Architecture
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
The Omi Windows application is a desktop port of the Omi ecosystem, implemented as an Electron application using React and TypeScript. Its primary purpose is to capture screen context and conversations, providing real-time transcription, summaries, and an AI-driven chat interface that utilizes the user's digital history as a "second brain."
The architecture follows a standard Electron multi-process model, separating the main process (system-level integration) from the renderer process (UI and user interaction). It integrates with Omi's shared Firebase infrastructure for authentication and data synchronization while maintaining local storage capabilities for privacy-centric operations.
Sources: desktop/windows/README.md:1-5, README.md:5-9
Core Tech Stack
The Windows application utilizes a modern JavaScript-based stack to ensure parity with the web and mobile components of the Omi ecosystem.
| Component | Technology |
|---|---|
| Framework | Electron |
| Frontend Library | React |
| Language | TypeScript |
| Build Tool | Vite |
| Authentication | Firebase Auth |
| Analytics | PostHog |
Sources: desktop/windows/README.md:3-33
Process Model & Data Flow
The application architecture is divided into three primary layers: the Electron Main Process, the Renderer Process, and External Services.
The diagram above illustrates the high-level relationship between the Electron processes and external cloud integrations.
Main vs. Renderer Process
- Main Process: Handles system-level tasks, including Google OAuth for desktop clients and managing secure environment variables provided at build time via Vite.
- Renderer Process: Manages the React-based UI, including the Knowledge Graph synthesis and chat interface. It communicates with the main process via Inter-Process Communication (IPC).
Sources: desktop/windows/README.md:21-40, desktop/windows/src/renderer/src/lib/kgSynthesisPrompt.ts:1-5
Knowledge Graph Synthesis
A critical feature within the desktop architecture is the synthesis of a Knowledge Graph (KG) derived from local machine evidence. This system extracts entities such as projects, people, and interests from active folders and user memories.
Synthesis Logic
The synthesis process uses specialized prompts to generate a semantic entity graph. To prevent hallucinations (e.g., inventing a tech stack), technologies are derived deterministically from real file extensions rather than LLM inference.
Logic flow showing how deterministic file scanning and LLM synthesis are merged to create the KG.
Data Structures
The KG synthesis utilizes specific types to structure information retrieved from the FileIndexDigest:
- Nodes: Contain
label,type(project, person, org, interest),summary, andsourceRefs. - Edges: Define relationships like "works on", "collaborates with", or "interested in".
- Source Constraints: The LLM is restricted to 60 memory lines to keep prompts bounded and ensure accuracy.
Sources: desktop/windows/src/renderer/src/lib/kgSynthesisPrompt.ts:7-35
Configuration and Environment
The application relies on environment variables for its operational modes. Vite inlines these values at build time, meaning that while a .env file is required for development, the values are compiled into the production binary.
| Variable | Description | Impact if Unset |
|---|---|---|
VITE_OMI_API_KEY | Syncs recordings to cloud. | Recordings saved locally only. |
VITE_ENABLE_GOOGLE_INTEGRATION | Enables optional Gmail/Google connect. | Google integration disabled. |
MAIN_VITE_GOOGLE_CLIENT_ID | OAuth Desktop client ID. | Sign-in works (shared FB), but Gmail integration fails. |
Sources: desktop/windows/README.md:27-44
System Integration Features
While the Windows port is an Electron application, it shares high-level goals with the macOS Swift implementation, focusing on background capture and user interaction.
- Authentication: Users sign in via a built-in popup using their individual Google or Omi accounts. This uses a shared Firebase project (
based-hardware). - Screen & Audio Capture: The app is designed to capture screen and conversation data, similar to the mobile and macOS counterparts, though specific Windows implementation details for capture are managed via the Electron main process.
- Local-First Privacy: By default, data stays local. Cloud synchronization is an opt-in feature requiring a specific API key generated from Omi settings.
Sources: desktop/windows/README.md:1-10, AGENTS.md:100-110, desktop/macos/AGENTS.md:50-60
Conclusion
The Omi Windows Desktop App Architecture leverages the Electron framework to provide a cross-platform bridge for Omi's AI capabilities. By combining deterministic file system analysis with LLM-driven synthesis, it builds a grounded, local-first knowledge base that empowers the user's AI assistant without compromising data integrity.