NIP-?? - Spam Mitigation with Zaps for Comments

[dhalsim]

[staab]

I love the idea, but I don't really think it's going to work.

• This increases friction for commenters, and for authors. I would at least remove the refund part, that's too much bookkeeping for something ao small.
• This only applies to replies, which are the worst kind of spam, but non-reply spam isn't touched.
• Relays still have to store and serve non-zap replies, and clie ts still have to download and verify them. So spam as a denial of service isn't touched (unless relays implement this nip too).
• This will lead to incompatible UX between clie ts that use this and ones that don't, similar to tge proposed nip 22 generic reply thing.
• Zaps are verifiable only by the zappee. Since there ia some trust in the author here, this isn't necessarily an objection, but it could weaken guarantees.

I like the idea of users getting paid for access to their content, and this is a soft way of doing that, but for preventing spam, using trusted realys (and maybe zapping them) I think would be much more effective and lightweight.

[dhalsim]

Thanks for the comments @staab ,

This increases friction for commenters, and for authors. I would at least remove the refund part, that's too much bookkeeping for something ao small.

Yes, but clients can help users to "zap back" quickly, while reading the comment you can hit a button and if you're using WebLN it is almost just a button click.

This only applies to replies, which are the worst kind of spam, but non-reply spam isn't touched.

Yes, other kind of spams are out of scope. I think PoW or other techniques are still relevant for a total spam mitigation.

This will lead to incompatible UX between clie ts that use this and ones that don't, similar to tge proposed nip 22 generic reply thing.

Your comments won't reach without you knowing why. I'll think about it more. I'm not sure about what NIP-22 is in this context though.

Zaps are verifiable only by the zappee. Since there ia some trust in the author here, this isn't necessarily an objection, but it could weaken guarantees.

Correct me wrong but can't you verify it has been received by looking at the preimage tag in the zap receipt?

[staab]

Your comments won't reach without you knowing why.

That's fair, maybe that would be ok.

Correct me wrong but can't you verify it has been received by looking at the preimage tag in the zap receipt?

I believe this does not prove value actually was transerred, although I am not an expert on zaps.

[jb55]

Correct me wrong but can't you verify it has been received by looking at the preimage tag in the zap receipt?

the preimage could just be random fake data that has nothing to do with a real lightning transaction. it doesn't mean anything.