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

Spam in Nostr, particularly in comment sections, is a growing issue. Spammers can easily generate thousands of comments without cost, overwhelming users. 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 (sats) to post comments.

## 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 (a small Bitcoin payment) 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, 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:

```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>"]
  ]
}
```

### 5. Relay & Client interactions

Clients `SHOULD`:
- Display an indicator when a note requires a zap for comments.
- Help the user pay the zap invoice and create the zap request event.
- Show whether a comment zap has been refunded or not.

Relays:

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 and ignore the rest.

### 6. 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).