Commit Graph
15 Commits
Author SHA1 Message Date
thePR0M3TH3ANandClaude Opus 4.8 7f6a0f3adf dm: try NIP-04 before NIP-44 for legacy kind-4 messages
orderDecryptors compared candidate `priority` before the `preferLegacy` flag.
The signer registers its nip44 candidate at an earlier priority (-20) than
nip04 (-10), so priority always decided the order and preferLegacy was dead
code — every kind-4 DM tried nip44 first, which fails on the `?iv=` NIP-04
ciphertext ("invalid base64: Unknown letter ?") before falling back to nip04.
That doubled the serialized extension round-trips per message on cold inbox
load and spammed the console.

Move the legacy preference (and it already had the explicit-hint check) above
the priority comparison so kind-4 messages attempt nip04 first. Gift-wrap
(preferGiftWrap) and same-scheme priority ordering are unchanged.

Regression: tests/dm-decryptor-order.test.mjs.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-06-23 21:36:15 -04:00
thePR0M3TH3ANandClaude Opus 4.8 2553072770 fix(dm): keep explicit hints + self-fallback in legacy decrypt ordering
The legacy-DM perf reorder regressed tests/nostr/dmDecryptorPreference:

1. preferLegacy short-circuited BEFORE the explicit-hint ranking, so a kind-4
   event tagged ["encrypted","nip44"] would still try nip04 first. Explicit
   hints now win; preferLegacy only flips the *no-hint* default.
2. The "skip the actor's own key" optimization dropped self even when it was the
   ONLY candidate (note-to-self DMs), leaving zero candidates -> ok:false. Self
   is now deferred to last and attempted as a fallback instead of dropped.

Spec correction (per Dark Factory rules): for a kind-4 DM with no hints, nip04
is now the preferred default (protocol-correct + avoids a wasted serialized
nip-07 round-trip). Rewrote the preference test to assert: nip04-first default,
explicit nip44 hint wins, nip04->nip44 fallback, and note-to-self decrypts.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-06-13 18:48:09 -04:00
thePR0M3TH3ANandClaude Opus 4.8 8171fcb347 perf(dm): persist decrypted DM results so reloads skip the extension
Consolidates the persisted-plaintext-decrypt-cache pattern (already used by watch
history) into a shared factory, persistedPlaintextCache.js, and adds a DM cache
on top of it. watchHistoryDecryptCache now delegates to the factory (same public
API; tests unchanged).

decryptDirectMessageEvent now also consults/writes a persisted cache keyed by the
immutable DM event id (JSON of the decrypt result; flushed once per
listDirectMessages batch; cleared on logout alongside the in-memory cache). DM
events never change, so a reload re-decrypts only messages it has not seen and
skips the (serialized, slow) nip-07 extension for the rest.

Harness (dm-repro, now cold/warm): 20 DMs -> COLD nip04.decrypt 50, WARM 0 —
reloads cost zero extension decrypt calls. Also excludes the actor's own key from
NIP-04 remote candidates (decrypting against self is always wasted). DM unit +
integration and watch-history cache tests green.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-06-12 19:55:07 -04:00
thePR0M3TH3ANandClaude Opus 4.8 bbf8d10473 fix(dm): stop the per-message extension decrypt storm in legacy DMs
The DM-repro harness (fake nip-07 extension) showed legacy DM history made ~12
extension decrypt round-trips PER message (20 DMs -> 241 calls: nip44.decrypt
121 + nip04.decrypt 120). At a real ~100ms extension latency that's ~24s, which
is why DM history "looked broken" — it was just catastrophically slow.

Two causes in decryptLegacyDm:
- It raced EVERY (decryptor x remote-pubkey) combination in parallel. That looked
  like a latency win, but the nip-07 extension serializes calls, so racing N
  combinations just queued N slow round-trips per message.
- orderDecryptors ranked nip44 first (by candidate priority), so every kind-4
  (always NIP-04) message burned a failing nip44 extension call first.

Fix: order nip04 first for legacy DMs (preferLegacy) and try candidates
SEQUENTIALLY, stopping at the first success. With the right scheme and remote
party tried first, it's ~1-3 calls/message instead of ~12. Harness after: 20 DMs
-> 60 calls, zero nip44 attempts (was 241). DM unit + integration tests green.

Adds scripts/perf/dm-repro.mjs (seeds kind-4 DMs, logs in via the fake extension,
calls listDirectMessages, reports decrypted count + extension call counts).

Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-06-12 19:43:49 -04:00
google-labs-jules[bot]andPR0M3TH3AN 56ffdb693d Refactor decryptLegacyDm to use ordered parallel race for decryptors.
Replaces Promise.any with raceOrdered utility to respect decryptor preference order while maintaining parallel execution.
Adds regression test for order preference.

Co-authored-by: PR0M3TH3AN <[email protected]>
2026-02-26 17:45:31 +00:00
google-labs-jules[bot]andPR0M3TH3AN a084bb59de refactor: deduplicate HEX64_REGEX to js/utils/hex.js
Moves the repeatedly defined HEX64_REGEX constant to a shared utility
module to improve maintainability and consistency. Updates all consumers
to import from the new location.

Signed-off-by: Jules <[email protected]>

Co-authored-by: PR0M3TH3AN <[email protected]>
2026-02-07 21:52:51 +00:00
thePR0M3TH3AN 81c329b87d Merge pull request #2128 from PR0M3TH3AN/perf/dm-decrypt-parallel-16182845594481363623
⚡ Parallelize DM Gift Wrap Decryption
2026-02-05 15:57:34 -05:00
google-labs-jules[bot]andPR0M3TH3AN 201e0d154f Parallelize DM Gift Wrap Decryption for lower latency
Co-authored-by: PR0M3TH3AN <[email protected]>
2026-02-05 20:52:35 +00:00
google-labs-jules[bot]andPR0M3TH3AN c696de37b7 optimize(dmDecryptor): use race pattern for legacy DM decryption
Verified that `decryptLegacyDm` uses `Promise.any` to parallelize decryption attempts, reducing latency significantly compared to serial execution.

Benchmarks showed:
- Serial execution: ~1258ms (worst case 5 decryptors * 5 candidates)
- Parallel execution: ~53ms

Added documentation comments to prevent regression and removed legacy `apply_fix.py` script.

Co-authored-by: PR0M3TH3AN <[email protected]>
2026-02-05 20:51:38 +00:00
google-labs-jules[bot]andPR0M3TH3AN b70c72faa4 ⚡ Optimize DM decryption with parallel execution
Refactors `decryptLegacyDm` in `js/dmDecryptor.js` to execute decryption attempts in parallel using `Promise.any`, replacing the sequential nested loop approach.

Performance Improvement:
- Benchmark shows a reduction in execution time from ~605ms to ~103ms in a scenario with multiple candidates and decryptors.
- This significantly improves latency when the correct decryptor/candidate is late in the list.

Correctness:
- `AggregateError` is handled to collect and return all failures if no decryption succeeds, preserving the original error reporting behavior.
- Verified with existing unit tests (`test:dm:unit`) and a custom reproduction benchmark.

Co-authored-by: PR0M3TH3AN <[email protected]>
2026-02-05 19:39:34 +00:00
google-labs-jules[bot] 4a0b81ad98 chore(ai): remove dead code (unused exports & deps) 2026-01-24 20:28:53 +00:00
thePR0M3TH3AN ef8307c560 Normalize giftwrap DM timestamps 2026-01-19 09:47:57 -05:00
thePR0M3TH3AN 4cc51d7a79 Add NIP-44 verification to DM decrypt worker 2026-01-19 09:40:51 -05:00
thePR0M3TH3AN fa2846afec Fix DM decryptor to try recipient keys for outgoing messages 2025-10-26 19:23:40 -04:00
thePR0M3TH3AN a534e20c10 Add DM decryptor and service integrations 2025-10-26 19:07:30 -04:00