Architecture¶
Runtime topology¶
InferencePort AI uses Electron’s process model:
Main process: window lifecycle, app menu, deep links, IPC registration
Preload: typed
contextBridgeAPI exposed to rendererRenderer: UI pages and user interactions
Node API modules: local file I/O, model orchestration, auth, utilities
High-level flow:
Renderer UI (public/*.html + scripts)
-> window.* APIs from preload.cts
-> IPC channels (ipcRenderer invoke/send)
-> node-apis/*.ts handlers in main process
-> local files, Ollama/OpenAI-compatible endpoints, Supabase services
Startup lifecycle¶
Key startup behavior from src/main.ts:
Acquire single-instance lock.
Register custom protocol
inferenceport-ai://.Register IPC handlers from: *
node-apis/ollama.ts*node-apis/utils.ts*node-apis/auth.ts*node-apis/spaces.tsCreate main browser window with preload script.
Attempt to start bundled/local Ollama service.
Fetch and cache tool-support metadata.
Deep links¶
Main process logic supports:
OAuth callback routes (
/auth/callbackand/authcallback)Generic path routing to matching files in
public/*.htmlQuery/hash passthrough for renderer initialization
Persistence model¶
Most data is stored under Electron app.getPath("userData").
Path |
Purpose |
|---|---|
|
Saved chat sessions and metadata. |
|
Cached list of models supporting tools. |
|
Binary assets generated during chat tool workflows. |
|
Local hosting/proxy server logs. |
|
Persisted Supabase auth session token payload. |
|
Profile-related local data. |
|
Imported/shared marketplace card metadata. |
|
First-launch marker used by onboarding logic. |
Security boundaries¶
Renderer does not directly access Node APIs.
Privileged operations are exposed only through preload bridge methods.
Markdown/HTML inputs are sanitized before rendering.
Proxy hosting uses token verification and role checks.