mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-11-15 00:09:08 -05:00
115 lines
5.4 KiB
Markdown
115 lines
5.4 KiB
Markdown
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 regular 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`.
|
|
|
|
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.
|
|
|
|
## 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 Assignment Event
|
|
|
|
The `.content` SHOULD remain empty.
|
|
|
|
The following tags MUST be present:
|
|
|
|
- A `e` tag to reference the **Bounty Event**.
|
|
|
|
- A `p` tag to reference the `pubkey` of the applicant chosen to complete the bounty.
|
|
|
|
- A unique `d` (could be the same as the `e` tag).
|
|
|
|
## 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.
|
|
|
|
2: **Assigned:** The bounty is has been assigned.
|
|
|
|
3: **Completed:** The bounty has been completed by the applicant and the creator has accepted the work. This can be inferred my the client by looking up a zap receipt referencing the **Bounty Event** and the assigned user's public key. The **Bounty Event** content should match the content found in the description of the **Bounty Application Event**. The reward should match in the zap receipt, **Bounty Event** reward tag and the reward tag found in the description of the **Bounty Application Event**.
|
|
|
|
## 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 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.
|
|
|