Skip to content
Qirava lowercase logo

Qirava DMS docs

Embedded & sync

The same engine that runs a server runs in-process inside a desktop or mobile app — no socket, RBAC intact. And because an embedded instance speaks the same op-frame as a cluster, it syncs both ways: offline-first locally, continuously backed up to the cloud, and restorable from it with an API key. This page covers the in-process library mode, the bidirectional WebSocket sync, and how backup and restore are just the two directions of that one sync.

The engine as a library#

On desktop (Tauri) and mobile, the engine links directly into the app and runs execute() in-process. The untrusted webview dispatches to an in-process worker — no socket — which fits Tauri's function-calls-only model and keeps the full RBAC pipeline intact. The at-rest key is scoped to the app id through the OS keystore.

In-process execute
the same one execute() + function registry, no network layer. The webview's calls land on a worker exactly like an HTTP request would.
RBAC intact
L1/L2/L3 still apply; the webview is just another untrusted caller. before-auth, function scope, and the planner gate all run unchanged.
OS-scoped key
at-rest encryption keyed per app id via the platform keystore.

Dual WebSocket sync#

Sync is bidirectional over a WebSocket, authenticated by an API key. The embed pushes its local operations up and pulls remote operations down, with origin-id tags to prevent echo loops. It is offline-first: the app works fully offline and reconciles when it reconnects.

 embedded DMS (in-process, offline-first) ──WebSocket, API-KEY auth──▶ cloud / cluster DMS
   DUAL = bidirectional op-frame sync (origin-id tags prevent echo loops):
     push local ops up   -> continuous BACKUP into the cloud
     pull remote ops down -> offline-first, multi-device
   RESTORE: a fresh embed authenticates with the API key -> replays the full
            stream down -> fully rehydrated. An embed is just a follower/forwarder over WS.
Embedded <-> cloud: dual op-frame sync over WebSocket

Backup & restore#

The push direction is a continuous backup — your local data streams into the cloud as it changes. Restore is the pull direction from empty: a fresh embed authenticates with the API key and replays the full stream down until it is fully rehydrated. Same op-frame, same path — backup and restore are just the two directions of the one sync.

Request

// fresh embed, empty store, holds an API key for the cloud instance
WS connect  cloud /sync   (auth: API key)

Response

// cloud streams the full op-frame history down; the embed applies each op in order

Output

// when the stream catches up, the embed is fully rehydrated and switches to live dual sync
// (push local ops up, pull new remote ops down) — no separate restore protocol.

Status#