itx-shivansh/aria

Purpose and Runtime

ARIA is a personal desktop AI assistant. Electron hosts the desktop process, React/Vite renders the UI, and Ollama supplies the default local LLM. It supports conversational assistance plus routed actions for WhatsApp, code, email, calendar, files, and system operations.

Primary startup boundaries:

• Electron main process: src/main.js

• Renderer preload bridge: src/preload.js

• React renderer root: src/renderer/app.jsx

• Electron packaging/runtime configuration: electron.config.js

Desktop Process and Renderer Boundary

src/main.js creates and controls the Electron application/window lifecycle. src/preload.js is the isolation boundary between privileged Electron/Node capabilities and browser-like renderer code; IPC should cross through this bridge rather than exposing direct system access to React.

The renderer is a local React interface, not a web deployment:

• src/renderer/index.html

• src/renderer/app.jsx

• src/renderer/chat/ChatWindow.jsx

User Interaction Surface

The main interaction is chat. ChatWindow.jsx collects prompts and presents assistant responses, while Sidebar.jsx and StatusBar.jsx provide application navigation/status context. The dashboard is a separate presentation area.

Relevant UI components:

• src/renderer/chat/ChatWindow.jsx

• src/renderer/dashboard/Dashboard.jsx

• src/renderer/components/Sidebar.jsx

Agent Orchestration Pipeline

ariaAgent.js is the central assistant coordinator. A typical request flow is: chat input → agent → intent classification → optional capability module → model response/action result → UI response. The agent also incorporates persistent conversation/context memory.

Core stages:

• Agent coordinator: src/agent/ariaAgent.js

• Intent routing: src/agent/intentParser.js

• Persistent memory: src/agent/memoryStore.js

This layer is the principal control boundary between natural-language reasoning and side-effecting integrations.

Capability Modules

Intent-selected modules isolate domain actions from core conversation handling. They represent the operational surface of the assistant and may require elevated local access or third-party authentication.

Key modules:

• WhatsApp automation: src/agent/modules/whatsappModule.js

• Code writing/debugging/execution: src/agent/modules/codeModule.js

• Email drafting: src/agent/modules/emailModule.js

• Calendar/scheduling: src/agent/modules/calendarModule.js

• File and system actions: src/agent/modules/fileModule.js, src/agent/modules/systemModule.js

AI Provider Boundary

The API layer abstracts LLM access from agent behavior. Ollama is the intended local runtime and requires a separately running ollama serve process and a pulled model such as llama3. Groq support appears to provide an alternate remote provider path, likely requiring credentials.

Provider routing and clients:

• src/api/aiRouter.js

• src/api/ollamaClient.js

• src/api/groqClient.js

External Dependencies and Operational Setup

Material runtime dependencies are Node.js 18+, Electron 31, React 18, Vite 5, and Ollama. WhatsApp functionality depends on whatsapp-web.js; setup UX is represented in src/renderer/components/WhatsAppSetup.jsx. Ollama setup guidance is surfaced through src/renderer/components/OllamaSetupGuide.jsx.

Environment-sensitive configuration is indicated by:

• .env.example

• package.json