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

rename to NIP-FF and broaden the definition of NUDs (everything is a NUD).

Browse Source
This commit is contained in:
fiatjaf 2024-11-11 21:48:00 -03:00
parent 7e34041997
commit fd3fa2e75c
3 changed files with 18 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
71.md
View File

@ -1,35 +0,0 @@
NIP-71
======
NUDs
----
`draft` `optional`
This NIP defines the creation of **NUD**s: _Nostr Unofficial Documents_, which are descriptions of standards and sub-standards that do not pertain to this NIPs repo.
Anyone can create a NUD and they are immediatelly valid as soon as they are published. NUDs have owners and can be modified by these owners at any time, but they can also be forked or reinterpreted by others. However as implementations of these specs mature they will naturally coalesce into some accepted definition and it won't be possible for anyone to change that anymore in practice (even if they change the document, the Schelling point will just move to some other document or other set of documents).
NUDs are defined as [NIP-54](54.md) **kind:30818** events.
They should have a `d` tag starting with `"nud:"` followed by a succinct and identifiable name so they can be referred to in other contexts.
For example:
```jsonc
{
{
"id": "a7696b56ac2af1db22b3a0caa27a84f01789bdd91d5e9eb497890a9597a0b339",
"pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
"created_at": 1714659471,
"kind": 30818,
"tags": [
["d", "nud:ordinals-comments"]
["title", "NUD: Ordinals Comments"]
],
"content": "# NUD: Ordinals Comments\n\nThis NUD defines how to comment on Bitcoin Ordinals using Nostr events.\n\nEvents should be of kind 10773 and include a tag in the format [\"o\", \"1928604426675219\"] in which 1928604426675219 is the satoshi number given by `ord`. Aside from that these events follow the rules of kind 1.",
"sig": "76bc8a799bb1f419a74b177e38ddb372358bc21f074848a8b8f1d9f21fc1d7d1f09ffe9d9fcc41ed7de405e102bb205100aadaa1e51ee54289e58f40ba55a8fd"
}
```
Aside from this NUD events follow all the rules of [NIP-54](54.md).

1
README.md
View File

@ -83,6 +83,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-96: HTTP File Storage Integration](96.md)
- [NIP-98: HTTP Auth](98.md)
- [NIP-99: Classified Listings](99.md)
- [NIP-FF: NUDs](ff.md)
## Event Kinds
| kind | description | NIP |

17
ff.md Normal file
View File

@ -0,0 +1,17 @@
NIP-FF
======
NUDs
----
`draft` `optional`
This NIP defines the creation of **NUD**s: _Nostr Unofficial Documents_, which are descriptions of standards and sub-standards that do not pertain to this NIPs repo.
Anyone can create a NUD and they are immediatelly valid as soon as they are published. NUDs have owners and can be modified by these owners at any time, but they can also be forked or reinterpreted by others.
NUDs MUST declare the event kinds they use and then those kind reservations SHOULD be taken into account in the NIPs big table of known kinds, with a link to the NUD.
Multiple forks of a NUD can exist at the same time -- although eventually it's natural that one of them becomes the _de facto_ winner. The NIPs repo SHOULD make reasonable judgements about which is which when considering what NUD to add to its big table (it's also ok to have multiple forks added, if there aren't clear winners).
The NIPs repo SHOULD make reasonable judgements about what NUDs to actually add to the big table in the first place, as some may not meet basic decency criteria or may not be used at all, so they SHOULD NOT be added, or they SHOULD be removed later if the assumptions change.