mirror of
https://github.com/PR0M3TH3AN/bitvid.git
synced 2026-10-27 07:52:24 +00:00
thePR0M3TH3ANandClaude Opus 4.8
96228a451b
The zap write path (zapSplit.js derivePointerTag) built the `a` coordinate tag straight from `videoEvent.kind`. bitvid's internal video objects don't always carry the Nostr kind — it can be 0 or undefined — and the inline builder only rejected non-finite kinds, so a kind-0 object produced a `0:pubkey:d` coordinate (Number.isFinite(0) === true). This flowed into both the kind-9734 zap request and the kind-30081 bitvid tally. The read side (zapTotals / mostZappedFeed) fetches totals by querying `30078:pubkey:d` via buildVideoAddressPointer, which defaults invalid/zero kinds to 30078. So the writer emitted `0:...` while the reader queried `30078:...` — they never matched and every zap counted as zero, even after a cache clear + refresh. Confirmed against live relays: 4 published bitvid tallies all carried `0:...` coordinates while the real video events are kind 30078. Fix: derivePointerTag now delegates to the same canonical buildVideoAddressPointer the reader uses, keeping writer and reader coordinates in lockstep. Adds a regression test driving splitAndZap with kind 0 / undefined / non-numeric video objects, asserting the zap request's `a` tag defaults to `30078:pubkey:d`. Co-Authored-By: Claude Opus 4.8 <[email protected]>