Poor Naughty List Identification

Issue Summary

We need to detect malicious behavior from clients and relays to protect our system from abuse, DoS attacks, and bandwidth exhaustion. This should feed into a reputation system or connection throttling/banning mechanism.

Types of Malicious Behavior to Detect

Invalid signatures:
- Events with bad/invalid cryptographic signatures
- Events claiming to be from public keys they don't control
Filter violations:
- Sending events that don't match requested subscription filters
- Clients sending EVENT messages when they should only be sending REQ/CLOSE
DoS/Resource exhaustion:
- Sending large amounts of unrequested data over the websocket
- Excessive message rates (flooding)
- Extremely large individual messages
- Connection spam (rapid connect/disconnect)
Protocol violations:
- Malformed JSON messages
- Invalid Nostr message types
- Messages designed to crash parsers or consume excessive memory

Requirements

Detection mechanisms:
- Track per-connection metrics (message count, bytes sent, error rate)
- Identify patterns of abuse vs legitimate heavy usage
- Differentiate between client errors and malicious intent
Response actions:
- Warning/throttling for minor infractions
- Temporary bans for repeated violations
- Permanent bans for severe malicious behavior
- Different handling for clients vs relay sync sources
NaughtyList integration:
- Add malicious relays to NaughtyList when detected via sync
- Track client connections separately (by IP or connection ID)
- Persistence across relay restarts

Investigation Tasks

Review existing validation in event handling pipeline
Check what metrics we currently track per connection
Identify all ingress points where abuse could occur
Research Nostr relay best practices for abuse prevention
Determine appropriate thresholds for rate limiting
Review NaughtyList implementation capabilities

Findings

(To be filled in during investigation)

Implementation Plan

(To be determined after investigation)

2.1 KiB Raw Blame History