NIP-09 deletion events accepted but addressable events still returned in queries

[BenGWeeks]

Summary

When publishing a NIP-09 deletion event (kind 5) with an a tag referencing an addressable event (kind 30402), the relay accepts the event (returns true), but continues to return the original event in subsequent queries.

Steps to Reproduce

1. Publish an addressable event (e.g., kind 30402 product listing)
2. Publish a kind 5 deletion event referencing it:

   {
     "kind": 5,
     "content": "Product deleted",
     "tags": [["a", "30402:<pubkey>:<d-tag>"]]
   }

3. Relay responds with true (accepted)
4. Query for kind 30402 events from the same pubkey
5. The "deleted" event is still returned

Expected Behavior

Per NIP-09:

Relays SHOULD delete or stop publishing any referenced events that have an identical pubkey as the deletion request.

After accepting the deletion event, the relay should stop returning the referenced addressable event in query results.

Actual Behavior

• Deletion event is accepted (publish returns true)
• Original addressable event is still returned in queries
• This causes deleted items to reappear in client UIs after refresh

Environment

• Relay: wss://relay.damus.io/ (running strfry)
• NIP-11 shows support for NIP-09: supported_nips: [1, 2, 4, 9, 11, 22, 28, 40, 70, 77]

Context

This was discovered while implementing product deletion in a Nostr marketplace. Full investigation details: PlebeianApp/market#413

Questions

1. Is this expected behavior (relay stores deletion but clients must filter)?
2. Should strfry be removing/hiding the referenced event from query results?
3. Is there a different approach for deleting addressable events?

[BenGWeeks]

Additional Findings

We added debug logging to investigate further and found something interesting:

Deletion Events Not Returned by Damus

When querying for kind 5 (deletion) events:

• 28 deletion events found - ALL returned by wss://nos.lol/
• 0 deletion events returned by wss://relay.damus.io/

[DEBUG] Found 28 deletion events
[DEBUG] Deletion event from relay: wss://nos.lol/ - tags: [Array(2)]
[DEBUG] Deletion event from relay: wss://nos.lol/ - tags: [Array(2)]
... (all 28 from nos.lol)

What This Means

1. relay.damus.io accepts the deletion event (publish returns true)
2. relay.damus.io still returns the original product in queries
3. relay.damus.io does NOT return the deletion event when queried for kind 5 events

So if a client was only connected to relay.damus.io, they would:

• See the product (kind 30402 is returned) ✅
• NOT see the deletion event (kind 5 is not returned) ❌
• Have no way to know the product was deleted

Comparison with Other Relays

• wss://nos.lol/ - Returns deletion events ✅, still returns product (client filters)
• wss://bugs.plebeian.market/ - Actually deleted the product (only 4 products returned, not 5)
• wss://relay.damus.io/ - Returns product, does NOT return deletion event

Questions

1. Is strfry configured to not store/return kind 5 events?
2. Should the deletion event be queryable so clients can implement client-side filtering?
3. Is this specific to the damus.io strfry configuration or a strfry behavior?