clients - add per host profiles (multiple setting profiles for one host) #12

Closed
opened 2026-07-28 14:35:09 +00:00 by enricobuehler · 1 comment
Owner

needs design work

open questions:

  • shared profiles for multiple hosts or really only per host?
needs design work open questions: - shared profiles for multiple hosts or really only per host?
Author
Owner

The design work is done — design/client-settings-profiles.md in the planning repo (432 lines, supersedes the older per-host-client-profiles.md, which only scoped single-profile per-host overrides and predates the settings revamp).

Answering the open question — shared, not per-host.

Profiles are a client-wide catalog, and the per-host part is only a binding. Reasons that settled it:

  • "Work" applied to three hosts should be one profile, not three copies that drift apart.
  • It dissolves the keying problem entirely. The binding lives as a field on the host record itself (KnownHost.profile_id / StoredHost.profileID), so there is no separate host-keyed map — and the known keying inconsistencies (Rust has no host UUID; addr:port vs fp_hex lookups) never touch this feature.
  • Multiple profiles per host still works, because a host has a default profile plus a "Connect with ▸ X" one-off that deliberately does not rebind.

Other decisions taken in the doc:

  • Sparse overlay, not snapshots. A profile overrides only the fields you touched; everything else keeps following the global defaults live. Snapshots drift and punish you for fixing a global once.
  • One settings UI. Profiles are edited in the existing revamped settings surface behind a scope switcher, never a second parallel editor.
  • Naming collision with the unshipped multi-user feature is settled: client settings bundles own the word "Profile"; multi-user's client-facing strings become "User" / "Connect as…". End state on a host card is "Connect as ▸" (who) and "Connect with ▸" (how). Only unshipped UI strings change.
  • The speed test finally writes to the profile the connection used, instead of clobbering the global bitrate — the sharpest existing symptom of this feature being missing.

Phasing is P0 (Rust core, no UI) → P1 Linux/Windows → P2 Apple → P3 Android → P4 fast-follows. P0 unblocks everything; P1–P3 are independent after it. The Android settings-parity leg rides along as its own phase, since the profile UX is built on the revamped settings structure Android is the last client to lack.

No wire, host, or protocol/ABI changes anywhere in this design — it is client-side only.

The design work is done — `design/client-settings-profiles.md` in the planning repo (432 lines, supersedes the older `per-host-client-profiles.md`, which only scoped single-profile per-host overrides and predates the settings revamp). **Answering the open question — shared, not per-host.** Profiles are a **client-wide catalog**, and the per-host part is only a *binding*. Reasons that settled it: - "Work" applied to three hosts should be one profile, not three copies that drift apart. - It dissolves the keying problem entirely. The binding lives as a field on the host record itself (`KnownHost.profile_id` / `StoredHost.profileID`), so there is no separate host-keyed map — and the known keying inconsistencies (Rust has no host UUID; `addr:port` vs `fp_hex` lookups) never touch this feature. - Multiple profiles per host still works, because a host has a *default* profile plus a "Connect with ▸ X" one-off that deliberately does not rebind. Other decisions taken in the doc: - **Sparse overlay, not snapshots.** A profile overrides only the fields you touched; everything else keeps following the global defaults live. Snapshots drift and punish you for fixing a global once. - **One settings UI.** Profiles are edited in the existing revamped settings surface behind a scope switcher, never a second parallel editor. - **Naming collision with the unshipped multi-user feature is settled**: client settings bundles own the word "Profile"; multi-user's client-facing strings become "User" / "Connect as…". End state on a host card is "Connect as ▸" (who) and "Connect with ▸" (how). Only unshipped UI strings change. - The speed test finally writes to the profile the connection used, instead of clobbering the global bitrate — the sharpest existing symptom of this feature being missing. Phasing is P0 (Rust core, no UI) → P1 Linux/Windows → P2 Apple → P3 Android → P4 fast-follows. P0 unblocks everything; P1–P3 are independent after it. The Android settings-parity leg rides along as its own phase, since the profile UX is built on the revamped settings structure Android is the last client to lack. No wire, host, or protocol/ABI changes anywhere in this design — it is client-side only.
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: unom/punktfunk#12