190 lines
9.3 KiB
Markdown
190 lines
9.3 KiB
Markdown
# 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.
|