Initial complete release

Initial fully functional release with extracted shared packages, README overview, client and server implementations.

Sync, Auth, Migrations

Working setup with syncing, authorization, and migrations:

• client app independent from client-lib
  • client "pure" frontend, specific for each app
  • client-lib shared services and hooks between clients for syncing and data management
• server data/schema independent, stores bytea (loro-crdt snapshot) and manages auth (tokens) and workspaces
  • Shared API definition inside packages/sync
• Schema and migrations defined in packages/schema (type-safe between server/client)

Adding a new app only requires creating a new client and setting up syncing using all the shared packages and server API (in theory 🫡)

First working version

Fully implemented API with auth and client integration.

Client

Primary local storage with IndexedDB (dexie+dexie-react-hooks) and loro-crdt.

Client gets assigned a clientId on first access (UUID). It can create a local workspace, which gets assigned a workspaceId (UUID). This client becomes the owner of the workspace.

It all works offline. Local-only (uncommitted) changes stored in temp_workspace table. When local data is synced, temp_workspace is cleaned and committed data is stored inside workspace table.

If client is connected to server (connection available), syncing happens on the background after every change after a debounce delay (Web Worker). Initial sync assigns the workspace to the client (owner) and sends back a master token. The token authorises successive sync push/pull.

The master client can then issue access tokens for other clients (given their clientId). The server creates a token (clientId+workspaceId), and the master client can share a link for the other client to join.

The master client can revoke access at any moment.

Server

Authorisation based on JWT token (clientId+workspaceId+isMaster). Middleware checks token for read/write access or master token access.

Initial load calls generateToken to assign master access to a client and perform initial sync.

Successive syncing is performed using pull (bootstrap or manual syncing) and push (client sends new changes). Both require a valid token (not expired or revoked).

Changes are still possible locally even if the token is invalid, but they are not synced until another token is issued.

Other endpoints manage issuing, listing, and revoking tokens.

Important

Data is application-independent. The database stores a bytea column with the exported snapshot from loro-crdt, it makes no assumptions on the shape of the data. This means that the server can be used for any kind of data and multiple applications. The server is only responsible for backup/syncing and authorisation.