nazim/avault
1
0
Fork 1
Code Issues 7 Pull requests 3 Projects Releases Packages Wiki Activity Actions

Daemon auto-recovery: agent restarts, operator approves via Amber #11

New issue
Open
opened 2026-02-27 14:07:00 +00:00 by nazim · 0 comments
nazim commented 2026-02-27 14:07:00 +00:00
Owner
Copy link

Problem

The daemon holds secrets in RAM after operator approves via Amber (NIP-46). If the daemon dies (crash, OOM, etc.), secrets are gone and nothing works until the operator manually restarts it.

Current state

  • Daemon code exists in avault.py (socket server, NIP-46 client)
  • Never actually been run or tested
  • No recovery mechanism
  • The nsec fallback (reading from ~/.profile) masks the problem entirely

Desired behavior

  1. Agent detects daemon is not running (avault daemon status or failed avault get)
  2. Agent runs avault daemon start
  3. Daemon connects to operator's Amber via NIP-46
  4. Operator gets notification on phone, approves
  5. Daemon decrypts nsec from nsec.enc, decrypts vault, serves via socket
  6. If daemon crashes later, agent repeats from step 1

The agent (bot) is responsible for keeping the daemon alive — not systemd. This is intentional: the operator must approve each restart via their signer.

Acceptance criteria

  • avault daemon start connects to Amber via NIP-46 and serves secrets
  • avault daemon status reports whether daemon is running
  • avault daemon stop wipes secrets and stops
  • avault get returns clear error when daemon is down (not silent fallback)
  • Test the full flow: start → Amber approve → get secret → stop → get fails
## Problem The daemon holds secrets in RAM after operator approves via Amber (NIP-46). If the daemon dies (crash, OOM, etc.), secrets are gone and nothing works until the operator manually restarts it. ## Current state - Daemon code exists in `avault.py` (socket server, NIP-46 client) - Never actually been run or tested - No recovery mechanism - The nsec fallback (reading from ~/.profile) masks the problem entirely ## Desired behavior 1. Agent detects daemon is not running (`avault daemon status` or failed `avault get`) 2. Agent runs `avault daemon start` 3. Daemon connects to operator's Amber via NIP-46 4. Operator gets notification on phone, approves 5. Daemon decrypts nsec from `nsec.enc`, decrypts vault, serves via socket 6. If daemon crashes later, agent repeats from step 1 The agent (bot) is responsible for keeping the daemon alive — not systemd. This is intentional: the operator must approve each restart via their signer. ## Acceptance criteria - [ ] `avault daemon start` connects to Amber via NIP-46 and serves secrets - [ ] `avault daemon status` reports whether daemon is running - [ ] `avault daemon stop` wipes secrets and stops - [ ] `avault get` returns clear error when daemon is down (not silent fallback) - [ ] Test the full flow: start → Amber approve → get secret → stop → get fails
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
kn/unified-owner-model
feat/install-script
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nazim/avault#11
No description provided.