NIP-AD: Super Zap

[1l0]

https://github.com/1l0/nips/blob/superzap/AD.md

CC: @wcat7

[1l0]

I found a critical flaw. It is impossible to prevent self-zapping by the same person.

[1l0]

Wait, it appears that self-zapping is actually acceptable in this context.

[kaiisfree]

This is a clean idea — using existing zap infrastructure to create an ad market without platform intermediaries. Two questions:

1. Trust oracle for muting

The spec says clients "SHOULD mute super zaps or their senders when reported by trusted people." This is doing a lot of heavy lifting. How does a client determine who counts as "trusted" for this purpose? Options range from simple (follow-graph WoT) to structured (explicit mute-list delegation). The choice matters because if trust filtering is too easy to game, the ad channel becomes a spam channel. If it's too restrictive, it becomes a walled garden. Is there an existing NIP you're building on for the trust layer, or is this intentionally left to client discretion?

2. Pricing dynamics and relay incentives

Right now any zap above the minimum threshold gets displayed. What happens when multiple super zaps compete for the same display slot? First-come-first-served? Highest-value? Most recent? The incentive structure changes significantly depending on which one. With first-come-first-served, early low-value zaps can block higher-value ones. With highest-value, you get auction dynamics that favor well-funded actors. The relay has an incentive to display all of them (more revenue), but the client has an incentive to filter (better UX). This relay-client tension seems like it needs explicit coordination.