Portable / offline client — Plex-style local library synced from a remote server

[jozef2svrcek]

Summary

Make the client useful standalone, "Plex-style": the heavy database (chess-db) runs on a desktop / personal server / VPS, and the laptop app carries a small offline library of selected content — prep for the next opponent, recently played games, opening repertoires — that stays usable with no server connection. When the server is reachable, the client gets the full experience; when it isn't, it falls back to the local library with a deliberately limited feature set.

Desired offline (server-less) functionality — intentionally limited

• Simple search over the local library (header-level: player / event / date / result).
• Replay games on the board.
• Replay an opening repertoire (repertoires are a possible future feature; a repertoire = PGN with variations).
• Record a just-played game locally (e.g. on the way home), to sync back later.

Explicitly out of scope offline: position/board search, dedup, player normalisation, FIDE — these stay server-side and are simply unavailable when disconnected.

Architecture

• Server = chess-db daemon (DuckDB, full features) on desktop/VPS — the source of truth.
• Client = thin Tauri app + the in-process chess-pgn engine (see Client cannot open large PGN files (>100 MB) for viewing #104), over a small local PGN library. Talks HTTP to the server when connected; uses the local library when not. No DuckDB / no daemon on the laptop.
• Interchange = PGN. The server already thinks in PGN + collections; the client stores PGN collections; sync moves PGN. One lingua franca ties both halves together.

This reinforces the #104 decision (lightweight, in-process, DuckDB-free engine) — you don't want a DuckDB daemon on a travel laptop for a few hundred prep games.

What already exists / maps cleanly

• Search + replay offline → the chess-pgn index + the existing chess.js board (Client cannot open large PGN files (>100 MB) for viewing #104).
• Record a game offline → already present as local-PGN tooling (AddGameModal / pgnEditor.ts / write_pgn_file); reframe as "add to your offline library", sync up later.
• Repertoire replay → PGN-with-variations already parses (parsePgnTree.ts) and navigates on the board; basic replay is essentially free (a richer drill/gap feature is separate/later).
• Local library → a folder of PGN collections + a small manifest. No schema/DuckDB. SQLite only if offline datasets grow large or we want fast sync-state tracking.

What is genuinely new (the real lift)

1. Sync / "pin for offline" (Plex "download"): mark server collections as available offline → server exports them as PGN to the client; local additions upload back (reuse the existing import/upload path). Needs a collection-export endpoint (the read-only export/backup jobs are a precedent) + a small sync/manifest layer. Keep the merge model simple to start: synced content read-only offline; local recordings append-only — sidesteps conflict resolution.
2. Secure remote access to the server over the internet (the Plex-hard part): the daemon currently binds 127.0.0.1 with no auth — fine on localhost, unacceptable exposed to a laptop across the internet to a VPS. Needs auth tokens + TLS (or a tunnel) and a hardened listener. Largest and most security-sensitive piece; do it deliberately and separately — must not block the offline engine.

Suggested sequencing

1. chess-pgn engine + local library (delivered largely via Client cannot open large PGN files (>100 MB) for viewing #104: index/search/replay over a folder of PGN collections; reuse existing add/edit for recording). Gives a standalone offline experience on its own.
2. Sync / pin layer (export-to-client, upload-local-back; read-only-synced + append-only-local).
3. Secure remote access (auth + TLS/tunnel) — its own project.

Notes / guardrails

• Keep the Client cannot open large PGN files (>100 MB) for viewing #104 lightweight-crate work bounded — do not let this ticket's remote-access/auth scope attach itself to it. The crate is a clean, shippable piece; secure-remote-server is a project of its own.
• Depends on Client cannot open large PGN files (>100 MB) for viewing #104 (the chess-pgn engine).

[jozef2svrcek]

Component breadcrumb for a possible companion mobile client (which #247's LAN server + token auth now makes architecturally straightforward — any HTTP client can drive the daemon):

annabilik/chessboard-native — a React Native chessboard, evaluated 2026-08-07:

• Design philosophy matches our thin-client model unusually well: "bring your own engine" — no rules, no legal-move validation, no engine code. LPDO's server owns all of that, so a render-and-gestures-only board is exactly the right shape.
• Controlled FEN-based API with a focus on "revision correlation, asynchronous decisions, stable annotation IDs" — the same async-position/annotation-identity problem class we solved in the desktop analysis board (Games page: 6-area analysis layout (opening explorer + board + game, read-only) #219/Analysis board: new page for editing a single game on a large board #220).
• Ships a react-chessboard-compat layer mirroring the API our desktop client already uses, which would ease sharing patterns between clients.
• Not usable for the current desktop app: React Native runtime (Gesture Handler/Reanimated/Worklets) can't run in the Tauri webview, and we already have react-chessboard working there.
• Maturity at evaluation time: v0.1.0, 3 stars, single maintainer, self-declared pending physical-device validation, targets React 19.2/RN 0.86. Watch, don't build on yet — re-evaluate against the RN chessboard field if/when a mobile client becomes real.