issue: update fc4d - clarify that deletion requests should always be broadcast

fc4d-rust-nostr-deletion-broadcast-behavior.md

@@ -9,13 +9,17 @@
 
 ## Problem Statement
 
-When ngit-grasp runs in "deletion request disrespector" mode (`deletion_request_disrespector = true`), it accepts kind 5 (NIP-09 deletion request) events but intentionally does NOT process them. The events should be:
+**Deletion requests (kind 5) should ALWAYS be broadcast to subscribers with matching filters, regardless of whether the relay honors the deletion.**
+
+When ngit-grasp runs in "deletion request disrespector" mode (`deletion_request_disrespector = true`), it accepts kind 5 (NIP-09 deletion request) events but intentionally does NOT process them (doesn't delete the target events). However, the deletion request events themselves MUST be:
 
 1. **Stored in the database** (for historical record)
 2. **Broadcast to active WebSocket subscribers** with matching filters (standard relay behavior)
 
 **Current uncertainty:** We need to verify that rust-nostr's `nostr-relay-builder` actually broadcasts kind 5 events to active subscribers when `WritePolicyResult::Accept` is returned from the WritePolicy.
 
+**Expected behavior:** Deletion requests are events like any other. Whether a relay chooses to honor the deletion is a separate concern from whether it broadcasts the deletion request event to subscribers.
+
 ### Why This Matters
 
 **Archive relay use case:**
@@ -94,27 +98,20 @@ If rust-nostr is accidentally not broadcasting kind 5 events when `WritePolicyRe
 - Accepted events should always be broadcast to matching subscribers
 - This is standard relay behavior regardless of event kind
 
-### Option 2: Add Configuration (if it's intentional)
+### Option 2: Fix Intentional Behavior (if it's by design)
 
 If rust-nostr intentionally doesn't broadcast kind 5 events:
 
-**Change:** Add configuration option to control kind 5 broadcast behavior
-
-```rust
-pub struct RelayOptions {
-    // ... existing fields ...
-    
-    /// Broadcast deletion requests (kind 5) to subscribers
-    /// When false, kind 5 events are saved but not broadcast
-    /// Default: true (standard relay behavior)
-    pub broadcast_deletion_requests: bool,
-}
-```
+**Change:** Remove special-casing of kind 5 events - they should follow standard event flow
 
 **Rationale:**
-- Some relays may want to suppress deletion request broadcasts
-- Archive relays need full transparency (broadcast everything)
-- Configuration provides flexibility for different relay policies
+- **Deletion requests are events, not commands** - they should be broadcast like any other event
+- **Separation of concerns:** Broadcasting events vs honoring deletions are separate decisions
+- **Standard relay behavior:** All accepted events should be broadcast to matching subscribers
+- **No configuration needed:** There's no legitimate reason to suppress deletion request broadcasts
+- **Transparency:** Clients should be able to see deletion requests regardless of relay policy
+
+**Strong position:** We should NOT add a configuration option to suppress broadcasts. Deletion requests are events and should always be broadcast. The relay's choice to honor or ignore the deletion is orthogonal to broadcasting the event.
 
 ### Option 3: No Change Needed (if configurable)
 
@@ -183,6 +180,13 @@ If rust-nostr already has a way to control this behavior:
 - **Uncertainty:** Need to verify this pattern applies to kind 5 events
 - **Next:** Investigate current behavior with test client, then examine rust-nostr source
 
+### 2026-01-15 [Session 10:15]
+- **Position clarified:** Deletion requests should ALWAYS be broadcast
+- **Rationale:** Deletion requests are events, not commands - broadcasting is separate from honoring
+- **Updated issue:** Strengthened stance against configuration options for suppressing broadcasts
+- **Key principle:** Separation of concerns - broadcasting events vs processing deletions are orthogonal
+- **Next:** Test current behavior, then prepare PR if needed (no configuration option, just fix)
+
 ## Notes
 
 **Key insight from user:**