🎯 Goal

Only relay or mark content that has been endorsed by a human via a zap (Nostr event kind:9735).

🏗️ Architecture Overview

Nostr Event --> Relay Pre-Processor
           |
           ├─ Check if event has a corresponding zap (kind:9735)
           |    ├─ If yes → Relay and optionally mark on-chain
           |    └─ If no  → Drop or queue event, awaiting a zap
           |
           └─ Store event and its zap linkage (via 'e' tag) in a cache

Implementation Steps

1. Parse Incoming Event

When a standard note event (kind:1) arrives at the relay:

• Extract the event ID (event.id).
• Store the event in a short-term buffer or a pending queue (e.g., Redis with a Time-To-Live of 1 hour).

2. Scan for Corresponding Zap Events

Continuously or on-demand, the system must scan for zap events (kind:9735) that reference pending notes:

• Query for zaps from your own relay (nos.xmark.cc) and optionally other major public relays.
• From each zap found, extract the e tag, which contains the ID of the event being zapped.

// Example Zap Event Structure
{
  "kind": 9735,
  "tags": [
    ["e", ""],
    ["p", ""],
    ["relays", "wss://..."]
  ],
  ...
}

3. Associate Zaps to Original Events

Maintain a simple, fast-lookup map to validate events:

• event_id → has_been_zapped (boolean)
• event_id → first_zap_timestamp

This map is used to make a filtering decision:

• If has_been_zapped is true, forward the original event for blockchain marking or relaying.
• Otherwise, keep the event in the pending queue until a zap is observed or the TTL expires.

4. Expose Zap Info in Event Pipeline

Before writing an event to the blockchain or relaying it, perform a final check:

• has_zap(event_id) → bool
• Optionally, include the zap confirmation in processing logs for monitoring and debugging.

5. Optional User Experience Tools

On front-end clients like xmark.cc or linkmark.xyz, you could display the status of a post:

• "Awaiting Human Endorsement (Zap)..."
• "Zapped ✔"
• Provide a clear "Zap this Post" button to encourage user validation.

🧪 Testing Protocol

1. Inject a known kind:1 event into the system. Verify it is placed in the pending queue.
2. Send a valid kind:9735 event that zaps the event from Step 1.
3. Ensure the original event is released from the queue and successfully passes through the filter only *after* the zap is processed.