PLAN: to do — users, with their own settings

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-22 17:36:53 -07:00
parent e558ca7ace
commit db214ebc2b
1 changed files with 25 additions and 0 deletions
@@ -350,6 +350,31 @@ something long in one, switch away and back, refresh — it's all still there.
    Downgrades are already refused by the installer's `vnum()` comparison; the updater
    should use the same rule.
 - **Users, with their own settings** — asked for 2026-09-22, not started. Today Ham Lab is
  one shared password: `config.json` holds a single `password_hash`, a login mints a session
  token in `state.json`, and everything a person can set — theme, accent colours, refresh
  rate, dashboard layout and its widgets — is stored per *machine*, not per person
  (`store.State.UI`, `.Dashboard`). So two people share one look, one layout, and one
  audit trail. Wanted: a username and password field, an account each, and settings that
  follow the account.
  - **The login.** A `users` list in `config.json` (name, hash, created, last seen) beside
    the existing hash, which becomes the first user on upgrade so nothing breaks. The
    session already exists and is already a token → just carry which user it belongs to.
    Argon2id or bcrypt as now; a login attempt must take the same time whether or not the
    user exists, or the form becomes a way to enumerate accounts.
  - **The settings.** `UI` and `Dashboard` move from one blob to one per user. Machine
    settings — the sampling rate, the history window, alert rules — stay machine-wide:
    they are facts about the box, not a preference, and the fleet is held to them.
  - **Decisions to make when it is built:** whether anyone can do anything (simplest, and
    honest for a household) or whether there is a read-only account — a viewer who can see
    graphs but not open a terminal, remove a container or shut a machine down; who may add
    and remove users; what happens to a user's terminals when their account is removed; and
    whether the hub's users are the fleet's, pushed like the sampling rate, or each machine
    keeps its own (each machine keeps its own is less surprising and less to go wrong —
    a hub already authenticates to a node with a token, not a password).
  - **Worth doing at the same time:** the log line every write already carries an IP should
    carry the user, and Settings → Access tokens should say which account issued each one.
 ## Open questions
 - Idle-session reaping policy (never / after N days) — leaning never; it's a