feat: add Impeccable themes (light + dark) + unified ProfileEditModal
- settings: add Theme::Impeccable / ImpeccableDark (serde rename impeccable-dark) - types: extend Theme union - styles: add :root[data-theme=impeccable] (oklch lacquer/kinpaku) and impeccable-dark (lacquer-deep), Alumni Sans display, editorial refinements - SettingsScreen: add Impeccable options with live swatch preview - ProfilesScreen: wire ProfileEditModal (Paper Lift) with segmented tabs, keep legacy modals for compat - DESIGN.md/PRODUCT.md + .impeccable/design.json from impeccable document
This commit is contained in:
parent
832e1144f0
commit
8366af7d86
10 changed files with 1258 additions and 3 deletions
47
PRODUCT.md
Normal file
47
PRODUCT.md
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
# Product
|
||||
|
||||
<!-- impeccable:product-schema 1 -->
|
||||
|
||||
## Platform
|
||||
web
|
||||
|
||||
## Users
|
||||
Primary: Linux Nostr users (daily use) who manage one or more keypairs and need to publish securely without exposing secrets. Situation: at their Linux desktop (X11/Wayland), switching profiles, composing notes, managing relays, and approving NIP-46 signing requests from other apps.
|
||||
|
||||
Secondary/expanded: Newcomers creating their first Nostr identity via a friendly GUI. The product is progressive — zero-to-first-profile onboarding is frictionless, but the same vault scales to power workflows (multiple profiles, CLI, remote signer). Success means the user can create, select, and publish as any profile, keep keys encrypted at rest, and never feel forced to paste an `nsec` elsewhere.
|
||||
|
||||
## Product Purpose
|
||||
Nostr Keynctr (Nostr Feed Manager) pairs a hardened Rust core with an Electron + React desktop shell so private keys never leave the machine. It makes self-custodied Nostr publishing practical: generate/switch profiles, compose with preview and rich attachments, publish with per-relay receipts, curate relays and feeds, and serve as a NIP-46 remote signer ("bunker") for other Nostr apps. Success is a trustworthy, local-first identity manager you can use daily, via GUI or the same Rust CLI.
|
||||
|
||||
## Positioning
|
||||
**Keys never leave the machine — and the architecture proves it.** The renderer never receives secret material; all key generation, signing, relay communication, and encryption happen inside the Rust backend over a JSON-lines IPC channel, with NIP-46 approval gating every external sign/decrypt request. A neighboring app could copy features, but cannot truthfully copy this verifiable separation while offering the same dual CLI + GUI surface.
|
||||
|
||||
## Operating Context
|
||||
Workflows: create/switch/delete/undo profiles, compose (Write/Preview, character count, up to 3 link previews, image pick → nostr.build upload with NIP-92 imeta), publish with per-relay receipts, feed aggregation (all vs. My contacts, 24h window), relay add/remove/enable/disable/test, NIP-05 assignment, secret reveal after unlock, vault backup, lock/unlock.
|
||||
|
||||
Environments: Linux desktop (Electron 33), Rust release backend (`target/release/keynectr serve` via stdio), Vite dev server optionally via `NOSTR_GUI_DEV_URL`. Data directory `~/.local/share/nost-feed-manager` (override `XDG_DATA_HOME`), vault `profiles_vault.json` (migrated from legacy Python CLI with timestamped backup), settings file alongside.
|
||||
|
||||
Rituals: single-click Approve/Reject for NIP-46 requests; explicit `window.confirm` for delete; 5s themed undo bar; publish confirmation toggle; per-relay status dots.
|
||||
|
||||
## Capabilities and Constraints
|
||||
Capabilities: profile create/switch/rename/set-picture/set-nip05/publish metadata; note publish with image imeta + link cards; feed aggregation and contact filtering; relay management and latency test; encrypted vault (AES-256-GCM + Argon2id), lock/unlock, set/remove password, reveal secret (hex + nsec); NIP-46 bunker; settings (theme light/dark/glass/neon, confirm_before_publish, shorten_npub); vault backup; CLI parity via same Rust crate.
|
||||
|
||||
Constraints (durable): local-only vault — no cloud sync; secrets encrypted at rest, derived key in-memory only and zeroized on lock/drop; renderer never sees secrets; dialogs/HTTP/media handled in Electron main, not renderer; files 0600, dirs 0700; NIP-98 auth for uploads; passwords via `NFM_PASSWORD` or prompt, never CLI args; CSP (`app://` prod vs devserver).
|
||||
|
||||
Decisions left open: whether undo_history should preserve full `StoredProfile` (currently `ProfileSummary` → secret lost on undo); long-term packaging/distribution; relay defaults.
|
||||
|
||||
## Brand Commitments
|
||||
Name: Nostr Keynctr / Nostr Feed Manager (early beta v0.1.0, MIT, Forgejo-hosted). Voice: friendly, security-explicit, no hype. Assets: `public/icon.png`, sidebar logo, `KeynectrAppIconPossibility02.jpeg` (untracked concept). No fabricated testimonials or benchmarks; existing copy in `README.md`, empty states, and settings descriptions is authoritative.
|
||||
|
||||
## Evidence on Hand
|
||||
Real content: Rust crate (`src/app, vault, crypto, profiles, publish, relays, signer, feed`), React screens (`Compose, Home, Profiles, Relays, Settings, Signer`), `frontend/src/lib/types`, `AppProvider` context, `fakeBackend` Vitest suite (99 tests), `CHECKPOINT-encryption.md`. No marketing site or pricing; no external testimonials to preserve.
|
||||
|
||||
## Product Principles
|
||||
1. **Keys never leave** — every feature must preserve the Rust/renderer boundary and approval gates; convenience never bypasses explicit consent.
|
||||
2. **Local-first, verifiable** — encrypt at rest, least-privilege files, per-relay receipts, and auditable IPC over transient convenience.
|
||||
3. **Progressive disclosure** — newcomer can succeed in two clicks; power user can stay in CLI or manage many profiles without UI churn.
|
||||
4. **One core, two doors** — GUI and CLI remain interchangeable via the same Rust engine; no feature lives only in one surface without justification.
|
||||
5. **Calm trust** — theming (light/dark/glass/neon) and microcopy earn confidence through precision, not loudness; undo and receipts make errors recoverable.
|
||||
|
||||
## Accessibility & Inclusion
|
||||
Linux desktop accessibility baseline (keyboard-navigable, focus-visible `var(--focus)`, screen-reader roles on status/alerts). No product-specific a11y standard declared; future work should keep contrast per theme tokens and ensure dialogs are dismissible via keyboard.
|
||||
Loading…
Add table
Add a link
Reference in a new issue