docs(checkpoint): first live Amber pairing succeeded, notifications root cause (2026-09-23)

CHECKPOINT-encryption.md

@@ -1,3 +1,63 @@
+# Checkpoint — FIRST LIVE END-TO-END AMBER PAIRING SUCCEEDED (2026-09-23 PM)
+
+## Where things are
+- Project: `/home/avi/Projects/Keynctr`
+- Branch: `master` @ **`a8d112b`** ("fix(ui): poll vault state so background
+  Amber pairing appears without reload"). Previous: `fb14976`
+  (checkpoint), `e02417b` (damus pairing relays), `8f055f7` (NIP-46 spec
+  fix + trace).
+- Working tree: clean for tracked files. Untracked intentionally NOT
+  committed: `COSMIC_THEME.md`, `KeynectrAppIconPossibility02.jpeg`,
+  `deferred/` (stays deferred).
+- Release binary: rebuilt at `e02417b`; `a8d112b` is frontend-only (no
+  rebuild needed — Electron loads the renderer from `frontend/dist`, rebuilt
+  via `npm run build`). Restart Electron to pick up the renderer change.
+
+## What was completed this session
+1. **ROOT CAUSE OF THE WHOLE SAGA — Amber's OS notification gate**: Amber's
+   in-app log showed all four `get_public_key` RPCs arriving on all relays,
+   each followed by `notifications disabled`. Amber's
+   `EventNotificationConsumer.consume` returns early when Android
+   notifications are blocked for the app — every signer request dies
+   silently after connect. Fix was on the phone: Settings → Apps → Amber →
+   Notifications → Allow. (Battery "unrestricted" was already set and was
+   never the issue.)
+2. **First live end-to-end pairing**: after enabling notifications, the next
+   scan completed in ~1s — `identity adopted:
+   npub=npub1f3tura29nrmhpp5v88z45knjejzdcx7ulvcz2jswau4raa7v25nsh6ltfw —
+   CONNECTED`. Vault holds the secretless `Nip46Client` profile as active;
+   connection re-keyed under the identity. Amber shows the app; desktop
+   Signer screens show Connected.
+3. **UI staleness found by the success (`a8d112b`)**: Home/Profiles read the
+   launch-time state snapshot and never refetch (IPC has no push channel),
+   so they still showed first-run Welcome after the background pairing.
+   `AppProvider` now polls `getState()` every 5s (cheap local read, errors
+   swallowed — screens surface their own failures).
+- Verification (all green at `a8d112b`): frontend `npm test` **119 passed
+  (17 files)**, `typecheck`, `lint`, `format:check`, `electron:build`,
+  `build` clean. Rust untouched (last green at `e02417b`: 211 unit + 4 e2e,
+  clippy/fmt clean, release green).
+
+## Commits added (newest first)
+- `a8d112b` fix(ui): poll vault state so background Amber pairing appears
+  without reload
+
+## How to resume / reproduce
+- Restart Electron (renderer changed), open Home/Profiles: the `Remote
+  Signer` profile (`npub1f3tura…`) is listed and active; state refreshes
+  within ~5s without reload.
+- Next: publish a note / sign through the paired Amber (approval appears in
+  Amber; `sign_event` path was e2e-tested, never yet live-tested).
+
+## Outstanding / next steps
+1. **Live sign/publish through paired Amber** (never exercised live).
+2. Prune the 11 stale profileless `nip46_connections` rows left by failed
+   scans (cosmetic; vault-only cleanup).
+3. `publish_profile_metadata` kind-0 via `Signing` (P2), KDF upgrade (Step
+   5), rename pass (Step 7) — unchanged.
+
+---
+
 # Checkpoint — Amber-side silence proven; damus rejoins pairing set (2026-09-23 PM)
 
 ## Where things are