nips/??.md

NIP-??
======

Spam Mitigation with Zaps For Comments
-----

`draft` `optional`

## Abstract

This NIP introduces a method for spam mitigation in comments by requiring a small bitcoin payment instead of relying on Proof of Work (PoW) as outlined in NIP-13. Users posting notes can require commenters to zap a specified amount of sats to prevent spam. If the comment is legitimate, the note writer is expected to pay back the commenter as a social rule. Refund process is entirely social, with no technical enforcement.

## Motivation

While NIP-13 provides a Proof of Work (PoW) mechanism to mitigate spam, it has notable downsides:

1. Spammers with access to dedicated PoW miners can bypass this barrier easily.
2. Honest users, particularly those with low-end devices or mobile phones, may find PoW too resource-intensive, leading to drained batteries or slowed performance.

This proposal seeks to create a more equitable and flexible spam prevention mechanism by requiring small bitcoin payments to comment on posts.

## Specification

### 1. The Writer's Requirement for Zaps

A user posting a note can include a tag to specify that comments on their note require a `zap` (NIP-57) to be accepted. This is done by adding a `require-zap` tag to their note:

```json
{
  "content": "Here is my new idea. I require some sats for comments",
  "created_at": 1723193276,
  "id": "<event-id-a>",
  "kind": 1,
  "pubkey": "<pubkey-a>",
  "sig": "...",
  "tags": [
    ["require-zap", "<amount-a>"]
  ]
}
```

### 2. The Commenter's Zap Request

To post a comment on a note with a `require-zap` tag, the commenter must create a zap request event in compliance with NIP-57. The zap request includes the required amount of sats in millisathoshies, and an `e` tag that links the comment to the original note:

```json
{
  "content": "I liked your idea! Thanks for writing this up.",
  "created_at": 1723193444,
  "id": "<event-id-b>",
  "kind": 9734,
  "pubkey": "<pubkey-b>",
  "sig": "...",
  "tags": [
    ["relays", "<relay1>", "<relay2>"],
    ["amount", "<amount-a>"],
    ["lnurl", "<lnurl-a>"],
    ["p", "<pubkey-a>"],
    ["e", "<event-id-a>"]
  ]
}
```

### 3. Zap Receipt

Upon receiving the zap payment, the receiver's LNURL server broadcasts a zap receipt event:

```json
{
  "id": "...",
  "pubkey": "<lnurl-a-pubkey>",
  "created_at": 1674164545,
  "kind": 9735,
  "tags": [
    ["p", "<pubkey-a>"],
    ["P", "<pubkey-b>"],
    ["e", "<event-id-a>"],
    ["bolt11", "..."],
    ["description", "<stringified-zap-request>"],
    ["preimage", "..."]
  ],
  "content": "I liked your idea! Thanks for writing this up."
}
```

### 4. Manual Zap Refund

As a social rule, if a writer requires a zap for comments, they are expected to refund the commenter if the comment is legitimate and not spam. The writer may choose to refund the zap by sending the same amount back via a new zap event, this time connecting the previous zap event with an `e` tag. a `zap-refund` tag is added to distinguish it from a normal zap.

```json
{
  "content": "",
  "created_at": 1723193555,
  "id": "<event-id-c>",
  "kind": 9734,
  "pubkey": "<pubkey-a>",
  "sig": "...",
  "tags": [
    ["relays", "<relay1>", "<relay2>"],
    ["amount", "<amount-a>"],
    ["lnurl", "<lnurl-b>"],
    ["p", "<pubkey-b>"],
    ["e", "<event-id-b>"]
    ["require-zap-refund", "<event-id-b>"]
  ]
}
```

Upon payment, the receiver's LNURL server broadcasts a zap receipt event, indicating the zap has refunded:

```json
{
  "content": "",
  "created_at": 1723193666,
  "id": "<event-id-d>",
  "kind": 9734,
  "pubkey": "<pubkey-b>",
  "sig": "...",
  "tags": [
    ["p", "<pubkey-b>"],
    ["e", "<event-id-b>"],
    ["P", "<pubkey-a>"]
  ]
}
```

## Client Interactions

Clients `SHOULD`:

- Display an indicator when a note requires a zap for comments.
- Help the commenter create a zap request event and pay the zap invoice.
- Help the note owner (writer) to pay back Zaps for Comments easily.
- Show whether a zap comment has been paid back or not.

## Relay Interactions

To mitigate spamming further, relays `MAY` ignore and refuse to propagate non-zapped comments, i.e zap receipt events. They can also apply different strategies like returning a `NOTICE` message for the first time receiving a non-zapped comment and ignore following ones.

## Flexibility in Usage

Writers have full control over the zap amount required for comments, providing flexibility to adjust based on the volume of spam they encounter. If a writer continues to receive spam, they can increase the zap amount. Writers can also decrease the zap amount for more legitimate engagement.

## Rationale

Using sats instead of PoW offers several advantages:
1. Anyone can send a comment using sats, even if they have a low-end device, without the resource-heavy demands of PoW.
2. Spammers are disincentivized by the direct financial cost of each comment.
3. Writers can adjust the required zap amount dynamically to reduce spam.
4. Writers are encouraged to refund legitimate commenters, fostering a fair, user-driven spam prevention system.

## Drawbacks

This system may discourage some users from commenting, even if they are not spammers, due to the required zap. Writers should consider the potential trade-off between receiving fewer comments and mitigating spam.

## Acknowledgements

Inspired by NIP-13 (Proof of Work) and NIP-57 (Zaps).