From db214ebc2b1a6dd1ebfd8cdcfc3d26d0f0a1a2f5 Mon Sep 17 00:00:00 2001 From: Mitchell-Johnson Date: Tue, 22 Sep 2026 17:36:53 -0700 Subject: [PATCH] =?UTF-8?q?PLAN:=20to=20do=20=E2=80=94=20users,=20with=20t?= =?UTF-8?q?heir=20own=20settings?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5 --- PLAN.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/PLAN.md b/PLAN.md index d5c97c6..48aa301 100644 --- a/PLAN.md +++ b/PLAN.md @@ -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