Files
soulseek-rs-modded/website
Michel de Graaf ab5cef8cfe docs: tell the whole daemon story, and stop denying it exists
An audit of the README and the site against the implementation found 38
places the docs were missing, stale, or wrong about daemon mode. Two were
outright false: the community page still answered "want a queue that
outlives the command?" with "slskd has that", and the home page promised
"no daemon, no API to stand up" fifty lines before the section that
describes both.

The download-box walkthrough now tells the truth about its sharp edges: a
pushed folder or share list is live-only on a remote daemon, whose own
config.toml wins at restart; `shares add` validates the path on the
machine you type it on; and a `get` that reaches its `--timeout` cancels
the daemon-side transfer. Its shell example also runs as written now — the
old block put a second command after a foreground daemon that never
returns.

The reference material catches up with the feature: `daemon` and its
subcommands join the command list, the config table gains the
daemon/daemon_token/--no-daemon rows, nine settings become eleven,
`daemon status` and `daemon token` get documented record shapes, exit 3
covers daemons, `queued` joins the serve statuses, the credential-free
count goes 13 to 19, and the action-command count 4 to 6.

And the surprises are written down rather than discovered: the daemon does
not sweep the wishlist on its own; Windows has no socket and so no
auto-attach; the attached TUI's settings form edits the daemon's folders
and rewrites this machine's config.toml; `serve` monitors a daemon's
uploads instead of starting a second server; `whoami` reports the
daemon's world, with --no-daemon as the way out. The OpenRPC section names
the six event methods and the session-wide download.set_dir rule.

Site typechecks, lints, and builds through prerender; every claim was
verified against the cited code before it was written.
2026-07-29 09:22:02 +02:00
..

website

The soulseek-rs project site. Vite + React + TypeScript + Tailwind v4, deployed to GitHub Pages by .github/workflows/pages.yml.

bun install
bun run dev        # http://localhost:5173/soulseek-rs/
bun run build      # client build, SSR build, then prerender
bun run typecheck
bun run lint

How the static site is produced

bun run build runs three steps:

  1. vite build — the client bundle, plus dist/index.html as the template.
  2. vite build --ssr src/entry-server.tsx — the same app compiled for Node.
  3. bun scripts/prerender.ts — renders every route in src/lib/routes.ts to its own file (dist/install/index.html, and so on) with that route's title and description substituted in, plus a 404.html.

Without step 3 GitHub Pages has no file at /install and answers a direct link with a 404. With it, every URL returns 200 with fully rendered markup, and the client hydrates that markup rather than replacing it.

Adding a page means: a component in src/pages/, a <Route> in src/App.tsx, and an entry in src/lib/routes.ts. The last one is what the prerenderer walks.

Design system

Tokens live in src/index.css, ported from the Claude Design project's tokens/colors.css. They are the same values that back the TUI in soulseek-rs/src/ui/styles.rs — change one, change both.

Dark is the native theme; light re-cuts the semantic hues roughly 10% darker, because phosphor and tape are legible on vinyl but wash out on manila. Theme selection is [data-theme] on <html>, defaulting to the OS setting, with an inline script in index.html applying it before first paint so the page never flashes the wrong background.

Notes

  • base in vite.config.ts is /soulseek-rs/ because this is a project site. Pointing a custom domain at it means setting that to / (the router reads import.meta.env.BASE_URL, so it follows automatically).
  • Copy in src/pages/ follows the project's tone of voice: plainspoken, precise, honest about limits first. No copyrighted artist or album names anywhere, including the TUI demo data in src/components/tui/data.ts.