nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-09 22:09:06 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Create nip1962.md

Browse Source
This commit is contained in:
gsovereignty 2024-02-19 01:11:32 +08:00 committed by GitHub
parent 36d2281587
commit 2fb90b1b4d
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 47 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
nip1962.md Normal file
View File

@ -0,0 +1,47 @@
# NIP-1962: NIP LIFECYCLE DEFINITION
#### STATUS: RAW
This document describes a lifecycle for interoperable Nostr Improvement Possibilites that seeks to engage the widest possible range of interested parties and move rapidly to consensus through working code.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119.
The primary goal of NIP-1962 is to facilitate the process of writing, proving, and improving new NIPs. A "NIP" defines event structures, protocols, processes, APIs, language usage, methodologies, or any other aspect of nostr that can usefully be documented for the purposes of technical or social interoperability.
NIPs should take minutes to explain, hours to design, days to write, weeks to prove, months to become mature, and years to replace.
NIPs have no special status except that accorded by the community.
NIPS use markdown publishing specifications.
Each NIP is a single markdown file, together with associated comments.
NIPs are assigned a number. New versions of the same specification MUST have new numbers.
A NIP has six possible states (raw, draft, stable, deprecated, retired, deleted) that reflect its maturity and contractual weight.
The lifecycle status of a NIP MUST be included at the top of the file using the same format as this NIP.
## LIFECYCLE STATUS
### RAW
All new NIPs are raw. Changes to raw NIPs can be unilateral and arbitrary. Those seeking to implement a raw specification should ask the NIP repository maintainers to elevate it to a draft specification. Raw specifications have no contractual weight.
### DRAFT
Draft NIPS are contracts between the editors and implementers.
When raw NIPs can be demonstrated in at least one implementation, they become elevated to *draft*. Changes to draft NIPs should be done in consultation with implementers.
### STABLE
Stable NIPs are contracts between editors, implementers, and end-users.
When draft NIPs are used by third parties, they become stable. Changes to stable NIPs should be restricted to cosmetic ones, errata and clarifications.
### DEPRECATED
When stable NIPS are replaced by newer draft NIPs, they become deprecated. Deprecated NIPs should not be changed except to indicate their replacements, if any.
### RETIRED
When deprecated NIPs are no longer used in products, they become retired. Retired NIPs are part of the historical record. They should not be changed except to indicate their replacements, if any. Retired NIPs have no contractual weight.
### DELETED
Deleted NIPs are those that have not reached maturity (stable) and were discarded. They should not be used and are only kept for their historical value. Only Raw and Draft NIPs can be deleted.