Context
keep-web (the StartOS co-signer) currently co-signs for a single FROST group at a time. Phase 1 (active-share model + Web Admin switcher, matching keep-android/keep-desktop) fixes the crash-on-multiple-groups and the bad recovery UX, but the box still serves only one group at a time.
Goal
For an always-on box holding shares for multiple keysets, co-sign for all groups simultaneously, so every keyset's clients get co-signs without an operator switching the active group.
Scope (larger, on top of Phase 1)
- keep-web backend: run one co-signer node + bunker per group concurrently.
- Per-group bunker identity (distinct connect URI per group), deterministically derived from the vault secret + group pubkey.
- Group-scoped API:
/api/groups with per-group state; scope peers, killswitch, bunker, signing-log, approvals, and WS events by group.
- Web Admin UI: render all groups (stacked cards), each with its own connection QR, presence/readiness, kill switch, approval bar, and activity.
- Decide whether to elevate keep-android/keep-desktop to simultaneous multi-group too (currently active-share), for full consistency.
Why deferred
Phase 1 (active-share) is the consistent, minimal fix that unblocks users now. Simultaneous serving is the better long-term model for always-on infrastructure but is a substantially larger change across the daemon, API, and UI (and possibly the mobile/desktop clients).
Context
keep-web (the StartOS co-signer) currently co-signs for a single FROST group at a time. Phase 1 (active-share model + Web Admin switcher, matching keep-android/keep-desktop) fixes the crash-on-multiple-groups and the bad recovery UX, but the box still serves only one group at a time.
Goal
For an always-on box holding shares for multiple keysets, co-sign for all groups simultaneously, so every keyset's clients get co-signs without an operator switching the active group.
Scope (larger, on top of Phase 1)
/api/groupswith per-group state; scopepeers,killswitch,bunker,signing-log, approvals, and WS events by group.Why deferred
Phase 1 (active-share) is the consistent, minimal fix that unblocks users now. Simultaneous serving is the better long-term model for always-on infrastructure but is a substantially larger change across the daemon, API, and UI (and possibly the mobile/desktop clients).