mirror of
https://github.com/PR0M3TH3AN/bitvid.git
synced 2026-10-27 07:52:24 +00:00
thePR0M3TH3ANandClaude Opus 4.8
bbf8d10473
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]>