mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-23 00:45:53 -05:00
make the bounty event parameterized replaceable event
This commit is contained in:
parent
2f53c48b93
commit
33a396a2f6
34
117.md
34
117.md
|
@ -12,11 +12,9 @@ This NIP defines a standard for creating, applying to and assigning bounties.
|
||||||
|
|
||||||
## Event Overview
|
## Event Overview
|
||||||
|
|
||||||
1. **Bounty Event:** defined as a regular event of kind 8050. This event is published by the creator of the bounty.
|
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 8051. This event is published by an applicant and should reference the **Bounty Event** with a single `e` tag.
|
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.
|
||||||
|
|
||||||
3. **Bounty Assignment Event:** defined as a parameterized replaceable event of kind 30050. This event is published by the creator of the bounty after receiving at least one applicant and should reference the chosen applicant by the public key associated with the **Bounty Application Event**. This event may be updated to change the associated `p` tag to a different applicant.
|
|
||||||
|
|
||||||
## Bounty Event
|
## Bounty Event
|
||||||
|
|
||||||
|
@ -28,9 +26,11 @@ The following tags MUST be present:
|
||||||
|
|
||||||
- A `reward` tag to provide a reward for the bounty. This is an array in the format `[ "reward", "<number>", "<currency>" ]`,
|
- A `reward` tag to provide a reward for the bounty. This is an array in the format `[ "reward", "<number>", "<currency>" ]`,
|
||||||
|
|
||||||
The following tags MAY be present:
|
- A `d` tag to provide a unique identifier for the bounty.
|
||||||
|
|
||||||
- Multiple `p` tags to notify users who may be interested in taking or reviewing 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.
|
- An `image` tag to show an image along with the bounty.
|
||||||
|
|
||||||
|
@ -40,6 +40,8 @@ The following tags MAY be present:
|
||||||
|
|
||||||
- A `context` tag to provide a link to a website or other resource that provides more information about the bounty.
|
- 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
|
## Bounty Application Event
|
||||||
|
|
||||||
The `.content` of these events should be a simple plain text string explaining why the creator should choose the applicant.
|
The `.content` of these events should be a simple plain text string explaining why the creator should choose the applicant.
|
||||||
|
@ -48,6 +50,8 @@ The following tags MUST be present:
|
||||||
|
|
||||||
- A `e` tag to reference the **Bounty Event**.
|
- 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:
|
The following tags MAY be present:
|
||||||
|
|
||||||
- A `timeline` tag to provide a date and time when the applicant expects to complete the bounty by.
|
- A `timeline` tag to provide a date and time when the applicant expects to complete the bounty by.
|
||||||
|
@ -72,15 +76,24 @@ The following is a description of the lifecycle of a bounty:
|
||||||
|
|
||||||
2: **Assigned:** The bounty is has been assigned.
|
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.
|
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
|
## 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.
|
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.
|
||||||
|
|
||||||
## Intentional Limitations
|
## Why is the Bounty Event Replaceable?
|
||||||
|
|
||||||
The bounties are intentionally not replaceable. This is to prevent the creator from changing the reward or other details of the bounty after it has been assigned. If the creator would like to change the content they may remove the bounty with a kind 5 event and repost.
|
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
|
## In Progress
|
||||||
|
|
||||||
|
@ -97,4 +110,5 @@ 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 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.
|
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 rejection event may also be published by the creator of the bounty if they choose to reject an applicant. This could be useful if the applicant is not qualified to complete the bounty. This could potentially be merged with the assignment event maybe by using the content field to "accept" or "reject".
|
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.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue
Block a user