History

Test User ab3bd7c63a docs: bring the book and every README up to date The docs drifted behind three changes: the /queues + /bookmarks + /captures split folding into one /crabidy provider, three providers arriving (soundcloud, jamendo, abs) with nothing written about them, and the spectrum toggle moving off v to f when library visual mode took v/V. - The book gains a page per undocumented provider — /soundcloud, /jamendo, /abs — each with its tree, its playback path, every config option, and how to log in. The providers index and intro list all nine roots in the order the server actually serves them. - Every provider now documents its login: Tidal's device flow (and that a broken tidaly.toml is the one fatal provider config), audiobookshelf API keys, the optional SoundCloud token and where to read it out of a browser, YouTube cookie exports, Jamendo's shipped key, and "nothing to do" for fyyd and /fs. - fsdy's README described three server-managed mounts under ~/.config/crabidy that have not existed for a while; it now describes /crabidy over the state dir plus the shared content store, and how deletes there never touch store audio. - Stale /captures/<name> save paths in the tidaldy and ytdy READMEs are /crabidy/<name>. The TUI key table, the README walkthrough, and the spectrum section use f, and visual mode (v/V) is documented. - config.md and the README list all seven provider config files, say plainly that credentials are stored in cleartext, and cover the audio output device; the CLI page documents audio-devices and features. - No README or docs page references architecture/, quality/, or plan/ any more: the book describes the system as it is, and points at the crate READMEs for usage and config. - devenv-docs.nix was never committed even though devenv.nix imports it, so a fresh clone could not enter the shell at all. It is in now, which also makes the README's `devenv shell -- docs` work. Also fixes two ./store.md links in providers/fs.md that pointed one directory too shallow. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>		2026-07-25 11:04:25 +02:00
..
src	web: show track times in mm:ss (or h:mm:ss), matching the TUI	2026-07-24 12:23:20 +02:00
.gitignore	Add a Leptos web client served by the server	2026-07-21 22:43:06 +02:00
Cargo.toml	Web client: scroll the keyboard cursor back into view	2026-07-23 18:36:09 +02:00
README.md	docs: bring the book and every README up to date	2026-07-25 11:04:25 +02:00
Trunk.toml	Add a Leptos web client served by the server	2026-07-21 22:43:06 +02:00
index.html	Add a Leptos web client served by the server	2026-07-21 22:43:06 +02:00
style.css	Add a server-streamed frequency spectrum visualizer	2026-07-21 23:14:03 +02:00

README.md

cbd-web — the browser client

A Leptos client-side WASM app with the same functionality as cbd-tui, served by crabidy-server itself.

How it works

Transport: gRPC-web (tonic-web-wasm-client) over the same generated client and proto types the TUI uses (crabidy-core). No second API surface — feature parity is structural. The server wraps its existing gRPC service in tonic-web, so the browser and the TUI hit identical /crabidy.v1.CrabidyService/… paths, and the same role auth layer gates both.
Serving: the built bundle (cbd-web/dist) is embedded into crabidy-server at compile time behind the default-on web-ui feature and served as the fallback route on port 50051. gRPC and static assets share one origin, so there is no CORS story.
Local-first: pure client-side rendering, every asset in the bundle (no CDN, no external fonts), library listings cached in memory like the TUI, credentials and theme in localStorage, and the update stream reconnects with backoff when the server disappears. There is no CRDT layer — this is a remote control for one live server state, not an offline-editing app (a deliberate departure from the web_client_example_workspace template that informed the toolchain).

Functionality

Everything the TUI does: browse the library (j/k/h/l, click), marks, create/rename/delete nodes (%/e/d), bookmark and capture (w/W, with live progress lines and skipped-track marking), the full queue and playback controls, volume, shuffle/repeat, and a ? help overlay listing the keys. Keys mirror the TUI; every key also has a clickable control. A light/dark theme follows the OS and can be toggled (persisted). The accent color is the crab orange-red.

When the server requires credentials, a login form collects the role (owner / queue-owner / queue-appender) and password; they are stored in localStorage and sent as the gRPC-web authorization header on every request.

Building

The WASM toolchain (trunk, wasm-bindgen, the wasm32-unknown-unknown target) is provided by devenv. From the repo root:

devenv shell -- build-web        # release bundle → cbd-web/dist
cargo build -p crabidy-server    # embeds cbd-web/dist

build-web clears RUSTFLAGS first: the native toolchain sets the mold linker, which rust-lld (the wasm linker) cannot parse.

Building crabidy-server without a cbd-web/dist present is fine — it embeds a placeholder page telling you to run build-web. To drop the web client (and the tonic-web layer) entirely, build the server without its web-ui cargo feature — e.g. --no-default-features --features all-providers,opus,spectrum; see docs/src/build-features.md.

Dev loop

Run a server, then a live-reloading trunk server that proxies gRPC-web to it:

cargo run -p crabidy-server      # or `cbd`
devenv shell -- serve-web        # trunk serve on http://127.0.0.1:8080

Trunk.toml proxies /crabidy.v1.CrabidyService to 127.0.0.1:50051, so the app behaves as if served from the server.

Tests

The DOM-free logic (pane/selection state machines, the keymap, capture progress formatting) lives in src/state.rs and src/keymap.rs and is unit-tested on the native target:

cargo test -p cbd-web

Components in src/app.rs stay thin over that logic. The server-side serving and the gRPC-web + auth routing are tested in crabidy-server (src/web.rs, tests/web_server.rs).