Reference

Dashboard

The dashboard decrypts and visualizes your survey responses in the browser — without your master seed ever entering a browser. It holds a subordinate, read-only, rotatable credential: the view seed.

The capability model

Your 12 seed words are the root of two parallel key hierarchies. The survey hierarchy (encryption keys) stays on your machine with the CLI. The view hierarchy derives one-way from the master seed: the view seed can re-create every per-survey view key, but nothing about it can walk back up to the master. Respondents seal each response to both keys, so either hierarchy can open it.

Your 12 words remain the single canonical backup: they re-derive the identity, every survey key, and the view seed. The view seed needs no backup of its own.

Pairing a browser

livybolt pair

1. The CLI derives your view seed, asks for a pairing password (it must differ from your identity password), and prints a QR code plus a copyable ncryptsec1… string. Both encode the same encrypted blob — the raw view seed never appears on screen or in the QR.
2. On the dashboard, scan or paste the code and enter the pairing password once.
3. The browser immediately re-wraps the view seed under your platform authenticator (Face ID / Touch ID / PIN via WebAuthn PRF), or a local password where that is unavailable. From then on, unlocking is one biometric tap. What sits in browser storage is ciphertext only — never the seed, never the PRF output.

How reads work

• Rediscovery — the dashboard walks view-key indexes and asks the public resolver (GET /api/surveys?view_pubkey=) which are registered: the same HD-wallet gap-limit scan livybolt vault rebuild runs. No account, no sync — any survey the CLI creates appears after a rescan.
• Authentication — every read carries a short-lived NIP-98 proof signed by that survey's view key. No session, no cookie, no stored token.
• Decryption — envelopes are fetched sealed and opened in the page with the per-survey view key. The server stores and serves ciphertext only.

Threat model, honestly

A dashboard is a served web page holding a secret while unlocked, and no amount of hardening changes what that means. Plainly:

• What a fully compromised browser gets: read access to your survey responses while a session is unlocked. An XSS on this origin that defeats the CSP could exfiltrate the view seed.
• What it can never get: your identity key, the ability to create surveys or spend sats, your master seed, or your other Nostr keys. The view seed is mathematically incapable of deriving any of them.
• The remedy is rotation: a compromised view seed is revoked from the CLI by rotating the view hierarchy — your master seed and surveys are untouched. (Rotation tooling is planned; until it ships, treat a suspected view-seed compromise as read-exposure of collected responses.)

Hardening in place: a nonce-based strict-dynamic Content-Security-Policy on the dashboard route (no inline scripts, no third-party origins, no runtime script CDNs), frame-ancestors 'none', and Trusted Types in report-only pending real-browser verification. This raises attacker cost; the residual XSS floor above is what remains, and it is the floor of any in-browser decryption design.

Losing things