how the desktop app is put together

opennbLM is an electron app. ui, privileges, and voice stay in separate processes so the renderer never talks to node, sqlite, or rumik directly.

rendererreact only

preloadtyped ipc

desktopmain process

boundaries

desktop owns windows, lifecycle, filesystem paths, and ipc handlers. it starts and stops local services and rumik.
preload is the only bridge. it exposes a narrow, typed api on window.opennbLM.
renderer is react. it must not import node or electron apis.
packages/ hold contracts, memory, providers, teaching, notebooks, and rumik. dependencies point inward through interfaces.

data

conversations and learner notes live in sqlite via sql.js (wasm), stored under the platform user-data path. the renderer never opens the database. credentials for cloud clis stay with those tools; the app does not keep a settings page of pasted api keys for the current engines.

teaching and voice

the teaching engine sits between the selected brain and what you read or hear. it asks for a structured plan, renders lesson text, and leaves wav synthesis to rumik. rumik is either local cuda inference or the built-in public space fallback. the renderer only receives sanitized status and audio paths.

packaging

windows ci builds an nsis installer. app code goes in an asar. optional rumik resources can live under extra resources. mutable state — the database, audio, preferences — stays in user data, not in the install directory.

workspace packages

contracts
engine-runtime
llm-providers
memory
local-services
notebook-runtime
teaching-engine
rumik-runtime

privacy terms docs