nips/43.md
Tommy Volk e0ecebd027 revamp
2024-02-08 09:44:37 -08:00

101 lines
5.1 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# NIP-43
## Bounties
`draft` `optional`
## Abstract
This NIP defines a standard for creating and providing solutions to 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 parameterized replaceable event of kind 30051. This event is published by a bounty applicant and MUST reference a **Bounty Event**.
## Bounty Event
_Describes some work that the creator is offering to pay someone to complete._
The `.content` of this SHOULD be a string text in Markdown syntax similar to [NIP-23](https://github.com/nostr-protocol/nips/blob/master/23.md#format). See the [complete state](#lifecycle-state-complete) in the **Bounty Lifecycle** section for details on the mutability-resistance of this field.
### Tags
The following tags MUST be present:
- A `title` tag to provide a title for the bounty.
- A `c` tag to specify the currency of the reward, for example: "BTC" or "USD". Fiat currency SHOULD conform to [ISO 4217](https://en.wikipedia.org/wiki/ISO_4217). For Bitcoin, use “BTC”. MUST be uppercase.
- A `reward` tag to specify a reward for the bounty. This is an array in the format `[ "reward", "<number>" ]`. Measured in the currency specified in the `c` tag. Denominated in whole units for fiat (i.e. for `c`=”USD”, 1=$1, 0.01=$0.01) and in sats for Bitcoin.
- A `d` tag to provide a unique identifier for the bounty.
- An `s` tag to communicate the current status of the bounty event. MUST be one of: `open`, `complete`, `withdrawn`.
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 `deadline` tag to provide a timestamp after which the bounty creator is no longer interested in receiving a solution. MUST be a stringified integer. Interpreted as a UNIX timestamp, in seconds.
- A `links` tag to provide links to external resources that provide more information about the bounty. This is an array where the first element is `links` and all subsequent elements are entries.
- An arbitrary amount of `t` tags that can be used as categories to filter bounties.
The following tags MUST be present when a bountys status (`s` tag) is `complete`:
- A `p` tag representing the public key of the user that provided the solution. See the `solution` tag below.
- An `a` tag to reference the **Bounty Application Event** accepted as the solution.
- A `solution` tag with the stringified **Bounty Application Event** signifying that it was chosen as the solution by the bounty creator.
The following tags MAY be present when the bounty is updated to `complete` status:
- A `zap_receipt` tag to reference the payment the bounty creator claims to have made to the creator of the accepted application.
## Bounty Application Event
_Describes the status of the work of an individual bounty applicant on a particular bounty._
The `.content` field SHOULD be updated with any relevant information regarding the solution of the bounty that the bounty applicant wishes to make public.
### Tags
The following tags MUST be present:
- A standard `a` tag to reference the **Bounty Event**.
- A `bounty` tag describing what the bounty applicant is applying to. MUST contain a stringified **Bounty Event**.
- An `s` tag to communicate the status of the bounty application event. MUST be one of: `applied`, `submitted`, `withdrawn`.
The following tags MAY be present:
- A `p` MAY be used to notify anyone that you have applied to this bounty.
## Bounty Lifecycle
The following is a description of the lifecycle of a [bounty event](#bounty-event):
1: **Open:** The bounty creator has not accepted any solution. This state is represented by an `s` tag of `open`. Bounties SHOULD begin in this state.
<a name="lifecycle-state-complete"></a>
2: **Complete:** The creator of the bounty has accepted a submission from a bounty applicant. This state is represented by an `s` tag of `complete`. The `.content` field of the **Bounty Event** MUST match the `content` field found in the `bounty` tag of the **Bounty Application Event** chosen as the solution. This “MUST” clause is to prevent the bounty creator from changing the description of the completed work after the bounty applicant has submitted their solution.
3: **Withdrawn:** The bounty has been withdrawn by the creator. This state is represented by an `s` tag of `withdrawn`.
## Bounty Application Lifecycle
The following is a description of the lifecycle of a [bounty application event](#bounty-application-event):
1: **Applied:** Communicates a user's interest in working on a bounty, making them a bounty applicant. This state is represented by an `s` tag of `applied`. Bounty Applications SHOULD begin in this state.
2: **Submitted:** A bounty applicant believes they have completed the work described in the bounty. This state is represented by an `s` tag of `submitted`.
3: **Withdrawn:** The bounty application has been withdrawn by the bounty applicant, indicating they are no longer interested in completing the bounty. This state is represented by an `s` tag of `withdrawn`.