feat: Implement Spam Protection using NIP-13 Proof of Work

[AbdelStark]

Description

To protect our Data Vending Machine (DVM) network from potential spam and abuse, we need to implement a spam protection mechanism using NIP-13 Proof of Work (PoW). This will require clients to perform computational work before submitting job requests, making it more costly to flood the network with spam.

Requirements

1. PoW Generation:

   • Implement a function to generate Proof of Work for nostr notes (job requests).
   • Allow configuration of difficulty levels for different types of requests or users.

2. PoW Validation:

   • Implement a function to validate the Proof of Work on incoming job requests.
   • Reject requests that don't meet the required difficulty level.

3. Difficulty Management:

   • Create a system to dynamically adjust difficulty levels based on network load.
   • Allow manual configuration of difficulty levels for different scenarios.

4. Client Integration:

   • Update the client-side code to perform PoW before submitting job requests.
   • Implement a background worker for PoW calculation to avoid blocking the main thread.

5. Relay Integration (assuming we want to deploy Askeladd custom relays):

   • Modify the relay to check PoW on all incoming job requests.
   • Implement proper error handling and feedback for rejected requests.

6. DVM Service Provider Integration:

   • Update the DVM service provider to verify PoW before processing job requests.

7. Monitoring and Logging:

   • Implement logging for PoW-related events (generation, validation, rejections).
   • Create metrics to track PoW difficulty levels and network load.

Implementation Steps

1. PoW Generation:

   • Implement the countLeadingZeroes function as described in NIP-13.
   • Create a generatePoW function that increments the nonce until the required difficulty is met.

2. PoW Validation:

   • Implement a validatePoW function that checks the difficulty of a given note ID.
   • Ensure the validation function also checks the committed target difficulty in the nonce tag.

3. Difficulty Management:

   • Create a DifficultyManager struct that can adjust difficulty based on network metrics.
   • Implement configuration options for setting base difficulty levels.

4. Client Updates:

   • Modify the job request creation process to include PoW generation.
   • Implement a background worker for PoW calculation in web clients.
   • Update mobile clients to handle PoW efficiently without draining battery life.

5. Relay Updates:

   • Add a PoW validation step in the relay's message processing pipeline.
   • Implement proper error responses for requests with insufficient PoW.

6. DVM Service Provider Updates:

   • Add PoW validation to the job request handling process.
   • Implement logic to reject or deprioritize requests with insufficient PoW.

7. Monitoring and Logging:

   • Set up logging for PoW-related events across all system components.
   • Create dashboards to visualize PoW metrics and network load.

Testing

1. Unit Tests:

   • Test PoW generation and validation functions with various difficulty levels.
   • Test difficulty adjustment logic under different network load scenarios.

2. Integration Tests:

   • Test the entire job request flow with PoW from client to relay to service provider.
   • Verify proper handling of requests with insufficient PoW.

3. Load Tests:

   • Simulate high network load to test dynamic difficulty adjustment.
   • Measure the effectiveness of PoW in preventing spam under load.

4. Client-side Tests:

   • Test PoW generation on various devices (desktop, mobile) to ensure performance.
   • Verify that PoW calculation doesn't significantly impact user experience.

Documentation

1. Update the project README with information about the PoW spam protection mechanism.
2. Create developer documentation explaining how to properly generate PoW for job requests.
3. Update user documentation to explain the purpose of PoW and any impact on request times.

Considerations

• Balance the difficulty level to deter spam without making it too burdensome for legitimate users.
• Consider implementing a system for "delegated PoW" as mentioned in NIP-13 for resource-constrained devices.
• Ensure that the PoW implementation doesn't unfairly advantage users with more powerful hardware.
• Consider privacy implications of PoW (e.g., could it be used to fingerprint users?).

Definition of Done

• PoW generation and validation functions are implemented and tested.
• Dynamic difficulty management is in place and responds to network load.
• All components (client, relay, service provider) properly handle PoW.
• Documentation is updated to reflect the new PoW requirements.
• Load tests demonstrate the effectiveness of PoW in preventing spam.

Resources

• NIP-13: Proof of Work