# Libre Study Roadmap Libre Study is the study workspace that consumes LibreBible packages. The current build is desktop-first, but the interface is already a React/Vite web app that can run in a browser. Tauri is the desktop shell and native storage layer, not a reason to fork the user interface. ## Current Code Baseline - UI: React and TypeScript, served by Vite in browser development mode and wrapped by Tauri for desktop builds. - Desktop shell: Tauri 2 with Rust commands and a local SQLite database at the app data path. - Browser development data: static LibreBible JSON/JSONL packages loaded from a sibling `libre-bible-data` checkout. - Current resource behavior: KJV and NET text, Strong's links, Strong's lexicon entries, KJV/NET footnotes and study notes, Matthew Henry Concise commentary, and Easton/Smith dictionary entries. - Current user workspace behavior: browser sessions, settings, notes, exported session JSON, note drawer, and session timeline are stored in `localStorage`. - Current gap: browser mode has the richer study-resource behavior, while Tauri SQLite import currently covers a smaller resource set. A shared service boundary is needed before public web hosting or desktop hardening. ## Architecture Rule Keep one application, not separate apps. Split the code by adapters: - Shared core: resource catalog reading, Bible page model, search model, session model, note/timeline model, and study-resource rendering rules. - Browser/web adapter: server API, account session, remote persistence, static resource package URLs, and optional collaboration services. - Desktop adapter: Tauri commands, local SQLite, local resource packages, offline cache, import/update manager, and no required account. The web version may add login and collaboration. The desktop version must remain usable without accounts. ## Phase 1: Current Baseline And Roadmap Goal: write down what the code already does and define the web/desktop direction before more feature drift. Tasks: - Record that Libre Study can become a website because the primary UI is already React/Vite. - Record that Tauri is the desktop wrapper and native storage path. - Record that accounts are web-only and should not be required for local desktop use. - Record maps, audio Bible, pronunciation audio, Nextcloud notes, collaboration, and database strategy in the roadmap. - Keep LibreBible resource data separate from user workspace data. Definition of done: - This roadmap exists in the app repo. - LibreBible's roadmap also names maps, audio, pronunciation, and web-consumption package needs. ## Phase 2: Shared App Core And Data Boundary Goal: stop treating browser mode and Tauri mode as separate realities. Tasks: - Extract a client/service interface for translations, pages, Strong's links, notes, commentaries, dictionaries, maps, audio, sessions, settings, and timelines. - Keep UI components pointed at that interface instead of hardcoding browser static paths or direct Tauri commands. - Add a clear resource catalog configuration path for browser, desktop, and future hosted web modes. - Define the session schema once: active translation, page anchor, selected verse, enabled resources, visual settings, notes, timeline, and exports. - Add a migration path from `localStorage` sessions to SQLite/server persistence. Definition of done: - The same UI can run against a browser static adapter, a Tauri SQLite adapter, or a future web API adapter. ## Phase 3: Storage And Search Foundation Goal: make hundreds of thousands or millions of entries feel normal. Tasks: - Keep SQLite for desktop and single-user/local workflows. - Add proper indexes for translation id, book/chapter/verse, Strong's number, lemma, resource id, and attachment relationships. - Add full-text search through SQLite FTS5 or a compatible indexed search layer. - Avoid loading entire large resources into the browser when a chapter, page, verse, Strong's entry, or search result can be loaded on demand. - Define when public web hosting should move from SQLite to Postgres or another server database. Definition of done: - Search, page loads, note loads, and Strong's lookups use indexed or sharded access instead of whole-library reloads. ## Phase 4: Private Web Alpha On Christ Unscripted Goal: get a private hosted version usable by Forrest without changing the desktop-first promise. Tasks: - Build the Vite app as a static web frontend. - Add a minimal server API for login, sessions, notes, settings, timeline, and resource catalog URLs. - Start with manually created accounts or a very small invite-only account flow. - Store only the minimum account data needed: username or email, password hash, sessions, notes, and timestamps. - Add a plain privacy note before opening this beyond private use. - Serve LibreBible packages as static files or through stable catalog URLs. Definition of done: - Forrest can log in on Christ Unscripted, open the study workspace, save a session, reload, and continue from the saved state. ## Phase 5: Notes, Exports, And Nextcloud Goal: make study work portable without making Nextcloud the primary database. Tasks: - Save notes as structured session data first. - Add export formats: JSON session, Markdown notes, HTML notes, and later sermon/study document formats. - Add Nextcloud integration through WebDAV as an optional sync/export target. - Support one-way export first, then explicit import, then optional sync. - Keep Nextcloud credentials out of public resource packages and out of desktop builds unless the user configures them locally. Definition of done: - A session's notes can be exported and optionally synced to a Nextcloud folder without breaking normal local or web persistence. ## Phase 6: Study Resource Depth Goal: continue turning the page into a complete study workspace. Tasks: - Add map support from LibreBible place/gazetteer packages. - Show map availability when a visible verse mentions a known place. - Add audio Bible support at chapter granularity first, then verse granularity when sources provide timestamps or verse files. - Add pronunciation audio tied to English terms, Strong's numbers, lemmas, Greek, and Hebrew where licensing permits. - Add more commentaries, dictionaries, lexicons, cross-references, and study-note packages. - Keep every resource optional, collapsible, session-aware, and license-attributed. Definition of done: - The study margin can show relevant maps, audio controls, pronunciations, notes, dictionary entries, lexicons, and commentaries dynamically for the selected verse or page. ## Phase 7: Collaboration Goal: add shared Bible study without turning the basic app into a social network. Tasks: - Start with shareable read-only session exports or links. - Add shared sessions with explicit owners and invited participants. - Add collaborative notes before collaborative whiteboards. - Record session timeline events per participant when timeline recording is enabled. - Consider WebSockets and a conflict-safe document model only after single-user web persistence works. Definition of done: - Two logged-in users can study the same passage and contribute to a shared note surface without losing individual session state. ## Phase 8: Desktop Hardening Goal: bring the installable app up to the same capability as the web study surface. Tasks: - Move desktop persistence from prototype imports to the shared session/resource schema. - Add resource package install/update management. - Add offline package support for translations, notes, commentaries, dictionaries, maps, and audio where storage size allows. - Keep account features optional and web-only unless a user explicitly signs into a sync service. - Package signed Windows installers from clean, pushed release commits. Definition of done: - The Windows app can run offline with installed resources and preserve sessions locally. ## Phase 9: Public Web Release Goal: open the hosted app responsibly after private use proves the model. Tasks: - Add account creation, password reset, rate limiting, backups, and basic abuse protection. - Add clear privacy, terms, license, and attribution pages. - Separate public resource data from private user notes and collaboration data. - Add admin controls for disabling accounts and reviewing operational health. - Add monitoring for failed logins, storage growth, and resource loading failures. Definition of done: - The hosted app can accept public users without guessing about data responsibility or resource licensing. ## Phase 10: Mobile And Future Platforms Goal: adapt only after the desktop/web study model is proven. Tasks: - Evaluate responsive web and PWA behavior first. - Consider mobile Tauri or native shells only if the PWA is insufficient. - Preserve the page-first study model while changing layout for smaller screens. Definition of done: - Mobile use is designed from the proven study workflow instead of forcing the desktop interface onto a phone. ## Database Decision SQLite remains appropriate for the desktop app and for private/single-user testing. Hundreds of thousands of rows are not a problem when tables are indexed and large resources are loaded by chapter, verse, Strong's number, or search query. For a public multi-user website, use SQLite only for a private alpha or low-concurrency service. Plan for Postgres or another server database once accounts, collaboration, and public user data become real.