nips/117.md

NIP-117
======

Bounties
------

`draft` `optional` `author:ChristianChiarulli`

## Abstract

This NIP defines a standard for creating, applying to and assigning bounties.

## Event Overview

1. **Bounty Event:** defined as a parameterized replaceable event of kind 30050. This event is published by the creator of the bounty.

2. **Bounty Application Event:** defined as a regular event of kind 8050. This event is published by an applicant and should reference the **Bounty Event** with a single `e` tag.

## Bounty Event

The `.content` of these events should be a string text in Markdown syntax similar to NIP-23.

The following tags MUST be present:

- A `title` tag to provide a title for the bounty.

- A `reward` tag to provide a reward for the bounty. This is an array in the format `[ "reward", "<number>", "<currency>" ]`,

- A `d` tag to provide a unique identifier for the bounty.

- An `s` tag to track the current status of the bounty: `open`, `assigned`, `canceled`.

The following tags MAY be present:

- An `image` tag to show an image along with the bounty.

- A `summary` tag to provide a short summary of the bounty.

- A `expiration` tag to provide a date and time when the bounty should be completed by.

- A `context` tag to provide a link to a website or other resource that provides more information about the bounty.

- A `p` tag of the applicant public key to track who is currently assigned to the bounty. **NOTE** This tag MUST be present when the bounty has the `assigned` status.

- An `application` tag with the stringified **Bounty Application Event**. **NOTE** This tag SHOULD be present when the bounty has the `assigned` status.

## Bounty Application Event

The `.content` of these events should be a simple plain text string explaining why the creator should choose the applicant.

The following tags MUST be present:

- A `e` tag to reference the **Bounty Event**.

- A `description` tag describing what the applicant is applying to containing the stringified **Bounty Event**.

The following tags MAY be present:

- A `timeline` tag to provide a date and time when the applicant expects to complete the bounty by.

## Bounty Lifecycle

The following is a description of the lifecycle of a bounty:

1: **Open:** The bounty is created and published by the creator and accepting applications. The bounty MUST be created with an `s` tag of `open`.

2: **Assigned:** The bounty has been assigned. The bounty MUST be updated with an `s` tag of `assigned` and a `p` tag of the applicant public key.

3: **Completed:** The bounty has been completed by the applicant and the creator has accepted the work. This can be inferred by the client by looking up a zap receipt referencing the **Bounty Event** and the assigned user's public key. The **Bounty Event** content MUST match the content found in the description of the **Bounty Application Event**. The reward MUST match in the zap receipt, **Bounty Event** reward tag and the reward tag found in the description of the **Bounty Application Event**.

4: **Canceled:** The bounty has been canceled by the creator. The bounty MUST be updated with an `s` tag of `canceled`.

## Motivation

Bounties will provide social incentive to complete tasks related to the development of Nostr and allow developers to get paid and build a reputation across the network.

## Why is the Bounty Event Replaceable?

So that we can track the status of the bounty which provides a way for the client to filter out bounties that have already been assigned.

We can work around this by making sure that the content and reward of the bounty event is the same as the content and reward found in the stringified **Bounty Event** in the **Bounty Event Application**. No **Bounty Event** without a matching reward across these three fields (including the zap receipt) will be considered complete. (Unless both parties agree to settle outside of the network)

If the creator changes the content or reward in an effort to scam the applicant, the applicant has a record of the original content and reward in the **Bounty Event Application**. And the bounty will not count as complete which will at the very least not improve the creators reputation.

If the applicant puts a fraudulent **Bounty Event** in the description of the **Bounty Event Application** the creator can choose not to pay.

Without an agreed upon 3rd party there will always be a way to scam the system. This is the best way I can think of to discourage scammers.
If the bounty was not replaceable, the creator could just delete the event anyway and skip paying after the applicant has submitted their work.

## In Progress

- This NIP may also provide a way for the creator and other users to pledge additional funds to the bounty after it has been created.

This would require at least 1 additional event to be published:

1. A **pledge** event of kind 8053 published by the creator of the bounty or any other user. (This may be another NIP entirely)

- This NIP may also provide a way for the creator and applicant to settle the bounty out of network if they choose to do so without a zap event.

This would require 2 events to be published:

1. A **settle** event of kind 8054 published by the creator of the bounty with an `e` tag referencing the bounty and a `p` tag referencing the applicant.
1. A **settle** event of kind 8054 published by the applicant of the bounty with an `e` tag referencing the bounty and a `p` tag referencing the creator.

A note can also be published along with the creation of the event referencing the bounty with an arbitrary list of p tags for users the creator thinks may be interested in reviewing or applying the bounty.

potentially make currency it's own tag so you can filter by currency.