fix dexie cache filter

[DanConwayDev]

by correcting the event format passed to nostr-tool's matchFilter

the dexie cache adaptor applies some simple filtering for efficiency reasons before using nostr-tool's matchFilter to apply the full NIP-01 ruleset

basic root cause analysis:

it is likely that nostr-tools changed the event format expected by matchFilter and this was missed during a dependancy upgrade for a number of reasons:

1. the use of as any remove type checking
2. nostr-tools doesn't use semantic versioning to highlight breaking changes
3. a cursory test using simple filters would have returned correct results

[erskingardner]

I'm not sure I understand the issue here? Is the cache adapter not returning the right results? Or returning no results?

[DanConwayDev]

in some cases the cache adatper returns too many results
take a filter that includes #a and #t
the correct behavior is to return events that match both #a AND #t
the cache adapter returns events for #a OR #t

it does this because it fails to call nostr-tool's matchFilter function correctly.

[erskingardner]

Gotcha, thanks. I'll respond on the other thread now.

[pablof7z]

hey @DanConwayDev -- finally had a chance to dig into this -- I think this PR is incorrect, the event you are using in this PR is the dexie representation of the event and not a nostr-tool compatible version.

I added a test to check and it seems the filter is being matched properly.

[pablof7z]

Hi @DanConwayDev — thanks for this fix. This PR is 8+ months old and targets the old path ndk-cache-dexie/src/index.ts. The package has moved to cache-dexie/src/ and the Dexie cache adapter has been refactored.

The matchFilter fix concept is solid, but would need to be verified and reimplemented against the current codebase.

Closing this as stale. If the filtering issue is still present in the current cache-dexie package, a fresh PR would be welcome.