WOT Relay Enhancement Plan

Overview

This document outlines the enhancement plan for the WoT Relay to add configurable hop counts and comprehensive moderation features including mute lists and NIP-56 report handling.

Current Architecture Analysis

Current Hop System

The relay currently implements a fixed 2-hop system:

• 1-hop (oneHopNetwork): Direct follows of RELAY_PUBKEY
• 2-hop (trustNetwork): Anyone followed by the 1-hop users who meet MINIMUM_FOLLOWERS criteria

Limitations:

• Fixed hop count doesn't allow for network size tuning
• Large well-connected accounts can dominate the trust network
• No ability to restrict trust network size for performance

Current Moderation System

Mute List Handling: The relay already fetches nostr.KindMuteList events but only for archival purposes, not for rejection filtering.

Report Handling: No current support for NIP-56 reports (kind 1984 events).

Enhancement Plan

1. Configurable Hop Count System

Motivation

The current 2-hop system works well for small networks but can become unwieldy as the relay owner follows popular accounts. Configurable hops allow:

• Network size control: Restrict trust network growth for performance
• Trust quality tuning: More hops = broader but less trusted network
• Resource management: Control API calls and memory usage

Implementation Design

New Configuration Fields:

MAX_HOPS int           // Maximum hops to consider (default: 2)
ENABLE_MULTI_HOP bool  // Toggle multi-hop functionality (default: true)

Environment Variables:

MAX_HOPS=2              # Can be set to 1, 2, 3, etc.
ENABLE_MULTI_HOP=true   # Can disable to use only direct follows

Algorithm Changes:

• Current: Fixed 1-hop → 2-hop traversal
• New: Configurable 1-hop → 2-hop → ... → N-hop traversal

Performance Safeguards:

• Per-hop network size limits (MaxTwoHopNetwork, MaxThreeHopNetwork, etc.)
• Exponential backoff for API calls at each hop level
• Memory monitoring with automatic hop reduction if needed

2. Enhanced Moderation System

2A. Mute List Filtering

Motivation:
Currently, mute lists are archived but not enforced for event rejection. This means:

• Muted users can still publish events to the relay
• The relay owner's moderation preferences are not enforced
• Additional moderation overhead is incurred without benefit

Implementation Design:

New Configuration Fields:

EnableMuteListFiltering bool   // Enable mute list rejection (default: true)
FetchMuteListFrom        string // "self" or "network" (default: "self")

Data Structures:

var muteListSet map[string]bool  // O(1) lookup for blocked pubkeys
var muteListMutex sync.RWMutex   // Thread safety

Fetch Strategies:

• "self": Only fetch mute lists from RELAY_PUBKEY (owner's blocks)
• "network": Fetch mute lists from all trusted users (community moderation)

Integration Point: Check mute list BEFORE trust network validation in RejectEvent callback.

2B. NIP-56 Report Handling

Motivation:
NIP-56 introduces standardized reporting (kind 1984) for objectionable content. Currently unhandled, this represents a missed opportunity for:

• Community moderation: Leverage collective judgment for content filtering
• Spam prevention: Filter consistently reported spammers
• Content quality: Improve signal-to-noise ratio

NIP-56 Specification Summary:

• Event Kind: 1984
• Tags: p (reported pubkey), e (reported event)
• Content: Report type (spam, harassment, illegal, etc.)
• Recommendation: Manual review, not automatic moderation

Implementation Design:

New Configuration Fields:

EnableReportFiltering bool     // Enable report-based rejection (default: true)
ReportThreshold          int   // Minimum reports before rejection (default: 3)
ReportTypes             []string // Which report types to consider
ReportDecayDays         int    // Days after which reports expire (default: 30)

Environment Variables:

ENABLE_REPORT_FILTERING=true
REPORT_THRESHOLD=3
REPORT_TYPES=spam,harassment,illegal,nsfw
REPORT_DECAY_DAYS=30

Data Structures:

var reportCount map[string]int        // pubkey -> report count
var reportDetails map[string][]Report // pubkey -> report details
var reportMutex sync.RWMutex

Report Processing Logic:

1. Collection: Fetch kind 1984 events from trusted sources
2. Counting: Track reports per pubkey and per event
3. Weighting: Reports from highly-trusted users count more
4. Decay: Reports expire after configured time period
5. Threshold: Reject when count exceeds threshold

Safety Considerations:

• Source verification: Only accept reports from trusted users
• Report type filtering: Configurable which report types matter
• Threshold tuning: Prevent false positives from coordinated attacks
• Appeal mechanism: Manual override capability

3. Integrated Moderation Pipeline

Decision Flow

When an event is received, the rejection logic follows this order:

1. Mute List Check (Immediate Rejection)

   • Is pubkey in muteListSet?
   • If yes: Reject with "user muted"
   • If no: Continue

2. Report Check (Threshold-Based Rejection)

   • Does report count exceed threshold?
   • If yes: Reject with "excessive reports"
   • If no: Continue

3. Trust Network Check (Current Logic)

   • Is pubkey in trustNetworkMap?
   • If no: Reject with "not in web of trust"
   • If yes: Accept

Rationale for Order

• Mute lists first: Direct moderation action, highest priority
• Reports second: Community judgment, medium priority
• Trust last: Network relationship, baseline filter

4. Implementation Strategy

Phase 1: Hop Configuration

• Add MAX_HOPS configuration
• Modify refreshTrustNetwork() for N-hop support
• Add per-hop limits and performance monitoring
• Update configuration loading

Phase 2: Mute List Integration

• Add mute list configuration and data structures
• Implement refreshMuteLists() function
• Integrate mute list checking into RejectEvent
• Add to periodic refresh cycle

Phase 3: Report System

• Add report configuration and data structures
• Implement refreshReportData() function
• Add report counting and threshold logic
• Integrate report checking into RejectEvent

Phase 4: Testing & Optimization

• Performance testing with various hop counts
• Report system effectiveness evaluation
• Memory usage optimization
• Documentation updates

5. Backward Compatibility

All enhancements maintain backward compatibility:

• Default values preserve current behavior
• Feature flags allow selective enablement
• Existing configuration unchanged
• Gradual rollout possible

6. Configuration Examples

Conservative Setup (Small, Trusted Network)

MAX_HOPS=1
ENABLE_MULTI_HOP=true
ENABLE_MUTELIST_FILTERING=true
FETCH_MUTELIST_FROM=self
ENABLE_REPORT_FILTERING=false

Moderate Setup (Balanced Approach)

MAX_HOPS=2
ENABLE_MULTI_HOP=true
ENABLE_MUTELIST_FILTERING=true
FETCH_MUTELIST_FROM=self
ENABLE_REPORT_FILTERING=true
REPORT_THRESHOLD=5
REPORT_TYPES=spam,harassment

Open Setup (Large, Community Moderated)

MAX_HOPS=3
ENABLE_MULTI_HOP=true
ENABLE_MUTELIST_FILTERING=true
FETCH_MUTELIST_FROM=network
ENABLE_REPORT_FILTERING=true
REPORT_THRESHOLD=3
REPORT_TYPES=spam,harassment,illegal,nsfw

7. Performance & Resource Impact

Memory Usage

• Hop expansion: O(n^h) where n is average follows, h is hop count
• Mute lists: O(m) where m is number of muted pubkeys
• Report data: O(r) where r is number of active reports

API Call Volume

• Current: ~100 calls per refresh cycle
• With 3 hops: ~10,000 calls (significant increase)
• Mitigation: Rate limiting, caching, staggered refresh

Database Impact

• No schema changes: All moderation data in memory
• Event storage: No change to existing event handling
• Index impact: None (mutes/reports not queried from DB)

8. Security Considerations

Attack Vectors

• Report spam: Coordinated reporting to silence users
• Mute list injection: Compromised mute list sources
• Hop explosion: Malicious follow patterns to bloat network

Mitigations

• Source verification: Only trust reports from high-trust users
• Rate limiting: Prevent rapid report/mute list changes
• Threshold tuning: Require consensus before action
• Manual override: Relay owner can bypass automated decisions

Conclusion

This enhancement plan transforms the WoT Relay from a simple 2-hop trust filter into a sophisticated moderation platform while maintaining the core trust network philosophy. The modular design allows for gradual implementation and tuning based on real-world usage patterns.

The key innovations are:

1. Configurable trust reach through hop count control
2. Layered moderation combining mute lists, reports, and trust
3. Community-driven moderation while preserving relay owner control
4. Performance-conscious design with safeguards and monitoring

This approach balances openness with safety, allowing the relay to scale while maintaining content quality through multiple, independent moderation mechanisms.