Offline and synchronization

Ramose treats offline support as a database property, not a UI cache. The configured database has one complete, authorized, principal-scoped local replica at an opaque revision.

Activation is lazy

Creating the database handle is synchronous and inert. Synchronization activates when the first observed query or mutation needs it.

Once activated, the database stays synchronized for that client session. A later session restores its last complete value and reactivates it lazily.

The committed replica is always complete

Initial synchronization installs a complete snapshot atomically. Resume applies each visible committed change atomically. The application sees the previous complete value or the next complete value, never half of a snapshot or transaction.

Query results are not persisted. Local indexes derive every answer from the database, which is why a query written tomorrow can still run over yesterday’s offline replica.

Optimistic state is layered

The visible local value is:

committed database
  + queued optimistic projection 1
  + queued optimistic projection 2
  + …

Commit installs the server result and removes the corresponding layer. Rejection removes only that layer, then replays later projections. The committed database never contains pending metadata; live entity handles expose it separately through .local.

The outbox survives failure

Invocations, client-created references, queue order, and receipts are persisted separately from the replica. Restart restores both the committed value and the exact speculative view. Reconnect resumes synchronization, submits in order, and uses durable server receipts to recover lost acknowledgements safely. A connection that dies leaves the queue retrying on its own timer and the reads offline until the tab’s next activation, which is when they activate again.

One browser, one replica

Tabs coordinate through browser locks, IndexedDB, and broadcast messages. One leader owns server synchronization; every tab can enqueue. If the leader closes or crashes mid-write, another resumes: the write landed whole or not at all, and queued work is never lost. A leader whose write is refused because another tab took over stands for election again. Where the browser offers no lock manager, every tab synchronizes for itself: correctness is unchanged, because concurrent writers converge on the same durable records, but the work is duplicated.

IndexedDB is what every tab agrees on. Broadcast messages only say that something changed and where; they order nothing and carry no values, so a tab reads the durable records. A tab that misses one — no broadcast channel, or a suspended tab — reads the same records on its next activation and reaches the same state, later rather than never.

Under storage pressure, Ramose reclaims content nothing reaches any more and retries the write; if that is not enough it fails with a typed quota error rather than discarding the replica. Authenticating a different principal under the same account selector fences every tab of the previous one through IndexedDB — including one still authenticating, and one that never saw a broadcast — before the replacement renders; a fenced tab withdraws what it was showing and activates again. Fencing withdraws, it does not delete, and signing out carries no such authentication at all — clearLocalData() is what removes an account’s data. A refused authentication leaves the client usable: auth() runs once per activation, so signing in again activates with the refreshed bearer the next time the tab gains focus or visibility. An in-page sign-in with no tab transition waits for one.

Security remains observable offline

Revocation, policy changes, catalog changes, and read-view changes cause authorized resets or removals. Hidden-only server activity produces no visible frames, count gaps, queue signals, or diagnostic metadata. Offline data is locally retained application data; use the same device and session threat model you would use for any offline-capable product.