nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-30 00:41:20 +00:00
Code Issues Packages Projects Releases Wiki Activity

design overhaul and cleanup

Browse Source
This commit is contained in:
Christian Chiarulli 2024-02-09 12:33:09 -05:00 committed by GitHub
commit 7c0da04c72
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 42 additions and 65 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

107
43.md
View File

@ -1,36 +1,38 @@
NIP-43
======
# NIP-43
Bounties
--------
## Bounties
`draft` `optional`
## Abstract
This NIP defines a standard for creating, applying to and assigning bounties.
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 regular event of kind 8050. This event is published by an applicant and should reference the **Bounty Event**.
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
The `.content` of these events should be a string text in Markdown syntax similar to NIP-23.
_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 `reward` tag to provide a reward for the bounty. This is an array in the format `[ "reward", "<number>" ]`,
- 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 `c` tag to provide the currency of the reward example: "sats" or "usd".
- 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 track the current status of the bounty: `open`, `assigned`, `canceled`.
- 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:
@ -38,86 +40,61 @@ The following tags MAY be present:
- 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 `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 `context` tag to provide a link to a website or other resource that provides more information about the bounty.
- 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 to provide a list of tags that can be used as categories to filter bounties.
- An arbitrary amount of `t` tags that can be used as categories to filter bounties.
The following tags MUST be present when the bounty is updated to `assigned` status:
The following tags MUST be present when a bounty’s status (`s` tag) is `complete`:
- A `p` tag of the applicant public key to track who is currently assigned to the bounty.
- A `p` tag representing the public key of the user that provided the solution. See the `solution` tag below.
- An `e` tag to reference the **Bounty Application Event**.
- An `a` tag to reference the **Bounty Application Event** accepted as the solution.
- An `r` tag with the stringified **Bounty Application Event**.
- 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
The `.content` of these events should be a simple plain text string explaining why the creator should choose the applicant.
_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 `r` tag describing what the applicant is applying to containing the stringified **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` tag to notify the creator of the bounty that the applicant has applied.
- A `timeline` tag to provide a date and time when the applicant expects to complete the bounty by.
- 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:
The following is a description of the lifecycle of a [bounty event](#bounty-event):
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`.
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.
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.
<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: **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**.
3: **Withdrawn:** The bounty has been withdrawn by the creator. This state is represented by an `s` tag of `withdrawn`.
4: **Canceled:** The bounty has been canceled by the creator. The bounty MUST be updated with an `s` tag of `canceled`.
## Bounty Application Lifecycle
## Solution Submission
The following is a description of the lifecycle of a [bounty application event](#bounty-application-event):
Solutions to bounties may be submitted via a nip-04 encrypted message to the creator of the bounty. Or however the client chooses.
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.
## Motivation
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`.
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.
Potentially split bounty into two events. One pre-assignment and one post-assignment. Pre assignment can be used to allow editing of the bounty so that the creator can add more funds or change the description. Post assignment can be used to track the status of the bounty and the assigned user without allowing the creator to change the bounty after assignment.
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`.