From bf10ae383aef2c40f10bd5a12395db39abcb4e54 Mon Sep 17 00:00:00 2001 From: Avi Date: Tue, 25 Aug 2026 11:52:43 -0500 Subject: [PATCH] Checkpoint: clarify NIP-42 status (already supported) --- CHECKPOINT-encryption.md | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/CHECKPOINT-encryption.md b/CHECKPOINT-encryption.md index 6f5884f..8387dfb 100644 --- a/CHECKPOINT-encryption.md +++ b/CHECKPOINT-encryption.md @@ -56,10 +56,28 @@ place: `runModalSave` in `frontend/src/screens/ProfilesScreen.tsx` ## Notes & next steps +- **NIP-42 status clarified (2026-08-25 addendum).** Earlier notes saying + "l484.com needs NIP-42 auth" described *raw probes* that don't answer + challenges — not a Keynectr gap. Verified: nostr-sdk 0.40 attaches the + signer in `Client::new` and enables NIP-42 auto-authentication by default + (`nip42_auto_authentication: true`), so AUTH challenges on read AND write + are answered automatically on every Keynectr path. Live test against + `wss://nostr.l484.com` replicating Keynectr's exact client setup: event + accepted in 0.3 s (inside the 6 s `RELAY_SEND_TIMEOUT`) and retrievable + afterwards. Known edge, left as-is by choice: the SDK's worst-case auth + dance (~7 s wait + resend) can exceed the 6 s watchdog on a very slow + authed relay → "did not respond in time"; healthy relays finish in <1 s. + Probe harness: `/tmp/opencode/nip42-probe` (throwaway key, same crates). - DRY audit items R1–R4 are all complete; nothing left on hold from that list. - Pre-existing clippy warnings in src/profiles.rs remain untouched by request. -- Relay health today: nos.lol 502, nostr.wine 403, l484.com needs NIP-42 auth, - nostr.band unreachable; primal/mom/soloco healthy. +- Relay health today: nos.lol 502 (intermittent), nostr.wine 403, + l484.com sends NIP-42 AUTH challenges but works fine with Keynectr + (auto-answered — see addendum above), nostr.band unreachable; + primal/mom/soloco healthy. +- Client visibility rule of thumb confirmed today: a note appears only on + clients whose read relays overlap the relays it was published to; if a + note "is missing" somewhere, first compare relay lists (Primal indexes + broadly; Iris/Yakihonne read narrower sets). ---