Transitive trust model
* Delegation: Alice (You) explicitly grant Bob authority.
* Transitivity: Alice implicitly accepts Carol's authority because Bob trusts Carol.
Result: Carol's moderation action (the spam signal) is immediately enacted on the content you see, even though you don't know Carol, because she is trusted by your chosen Delegate, Bob. As this is opt in and you can always audit the behavior it is pretty simple to build a large network of personal curators.
Application to Nostr Relays
The Problem for Nostr Relays is that they want to offer high-quality content without being overwhelmed by spam, bots, or scam accounts. Since they can't manually review every single user, they need a robust, decentralized mechanism to determine which Nostr public keys (\text{pubkey}) to accept.
The Solution: Delegated Whitelisting
This system transforms the spam signal from a content removal action into a \text{pubkey} removal/de-whitelisting signal.
1. Setup: The Relay Delegation
* The Relay Operator chooses a set of trusted, long-standing users/curators (the Level 1 Delegates).
* Example: Nostr Relay (\text{N}_\text{relay}) trusts Bob (a well-known Nostr curator) and David (a high-signal Nostr user).
* Event: A new Nostr user, Eve (\text{pubkey}_\text{Eve}), starts spamming.
* Action: Carol sees Eve's spam and uses a designated client/tool to issue a "Spammer Flag" against \text{pubkey}_\text{Eve}.
* Propagation: The Relay receives the "Spammer Flag" and verifies the chain:
* Is Carol trusted by Bob? (Yes)
* Is Bob trusted by the Relay? (Yes)
* Enforcement: Because the chain is valid, the \text{N}_\text{relay} removes \text{pubkey}_\text{Eve} from its whitelist.
* Result: The Relay no longer accepts posts from Eve, thus dramatically reducing spam for all users connecting to that Relay.
Alternatively eve’s account could be simply penalized by the relay with a slow down or rate limiting action.
A relay may choose to wait for additional confirmations from other trusted curators trust chains to flag spam posts before removing a spammer. This could be built into the relay policy settings.
4. The Opt-In Aspect
This is the Relay's opt-in choice. The Relay explicitly chooses to delegate its \text{pubkey} management authority to Bob (and transitively, to Carol). Any Relay operator that does not opt-in to this system must use its own, centralized method for spam control.
This allows Relays to outsource trust and moderation to the decentralized human network, making the relay ecosystem more resilient and cleaner.
Monetizing the relay network should be separate from the spam control. We don’t need toll gates for this stuff.