nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-13 23:39:08 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity
7c0da04c72
nips/43.md
Tommy Volk e0ecebd027 revamp
2024-02-08 09:44:37 -08:00

5.1 KiB
Raw Blame History

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. See the complete state 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. 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 bounty’s 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:

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: 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:

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.