What happens
When a Damus user connects to our Nostr relay, we occasionally receive a severely non-compliant REQ message.

The full message payload received is:

["REQ", "xxx", {"ids":[null], "limit": 1}]

This filter object violates the NIP-01 specification because the ids array contains null.
Event IDs must be represented as 64-character hexadecimal strings. The presence of null is an invalid data type within the ids array.

What I expect to happen
I expect Damus to send valid REQ messages only. If ids are included in the filter, the array must contain only valid event ID strings. If no specific ID is available (e.g., if a lookup failed internally), the ids field should be omitted entirely or an empty array [] should be used, not [null].

Link to noteID, npub

Screenshots/video recording
The full message payload captured from the relay log:

["REQ", "xxx", {"ids":[null], "limit": 1}]

** Versions **
Damus version: [Unknown / Observed on Recent Traffic]
Operating system version: [Unknown (likely iOS/macOS)]
Device: [Unknown]

ping @Hakkadaikon ?

Steps To Reproduce
Steps to reproduce the behavior:

1. Operate a Nostr relay server that logs incoming REQ messages.
2. A user connects via Damus.
3. The relay receives a REQ message with the exact payload: ["REQ", "xxx", {"ids":[null], "limit": 1}].

Additional context
This issue was discovered while analyzing relay logs. It occurs very rarely from Damus users. The presence of {"limit": 1} alongside {"ids":[null]} suggests the client is likely trying to fetch a single, specific event (possibly by an internal ID or lookup result that resolves to null), but the filter construction logic incorrectly serializes the null value into the ids array instead of handling the missing ID gracefully. This non-compliance forces relays to handle invalid data.