mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-11-12 23:19:08 -05:00
nip "Replaceable Versioned Events"
This commit is contained in:
parent
b6f8a6e79b
commit
628902cae0
4
33.md
4
33.md
|
@ -6,7 +6,9 @@ Parameterized Replaceable Events
|
|||
|
||||
`draft` `optional` `author:Semisol` `author:Kukks` `author:Cameri` `author:Giszmo`
|
||||
|
||||
This NIP adds a new event range that allows for replacement of events that have the same `d` tag and kind unlike NIP-16 which only replaced by kind.
|
||||
This NIP adds a new event range that allows for replacement of events that have
|
||||
the same author, first `d` tag and kind unlike [NIP-16](/16.md) which only
|
||||
replaced by kind.
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
|
|
85
34.md
Normal file
85
34.md
Normal file
|
@ -0,0 +1,85 @@
|
|||
NIP-34
|
||||
======
|
||||
|
||||
Parameterized Versioned Events
|
||||
--------------------------------
|
||||
|
||||
`draft` `optional` `author:Giszmo`
|
||||
|
||||
This NIP adds a new event range that allows for versioning of events that have
|
||||
the same author, first `d` tag and kind but unlike [NIP-33](/33.md), no events
|
||||
get discarded, keeping references by event ID intact.
|
||||
|
||||
Reasoning
|
||||
---------
|
||||
For maintaining bodies of events between multiple authors, relying on the
|
||||
good-will of others to not change or delete their respective events is not good
|
||||
enough. For example for wikipedia or nip registry replacements, we need ways to
|
||||
know an acceptable version of the document stays around without having to copy
|
||||
it under another author's pubkey.
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
A *Parameterized Versioned Event* is defined as an event with a kind
|
||||
`40000 <= n < 50000`.
|
||||
|
||||
It follows the same rules as NIP-33 except that "replaced" events do not get
|
||||
discarded.
|
||||
|
||||
Relays queried for `author:kind:d-tag` tuples serve the last but when queried
|
||||
for specific event IDs, those will be returned, too.
|
||||
|
||||
A Use Case
|
||||
----------
|
||||
A later nip might define a nip registry such that authors can either publish
|
||||
their own preferred version of a nip or e**n**dorse others by
|
||||
`author:kind:d-tag` tuples or by event ID.
|
||||
|
||||
Alice proposes NIP-999:
|
||||
|
||||
```
|
||||
"author": $alice,
|
||||
"id": "14aeb..8dad4",
|
||||
"kind": 40001,
|
||||
"tags": [
|
||||
[ "d", "999"],
|
||||
…
|
||||
```
|
||||
|
||||
Bob endorses exactly that version:
|
||||
|
||||
```
|
||||
"author": $bob,
|
||||
"kind": 40001,
|
||||
"tags": [
|
||||
[ "d", "999"],
|
||||
[ "n", "14aeb..8dad4"]
|
||||
],
|
||||
"content": "",
|
||||
…
|
||||
```
|
||||
|
||||
Carol endorses whatever Bob wants to see as NIP-999:
|
||||
|
||||
```
|
||||
"author": $carol,
|
||||
"kind": 40001,
|
||||
"tags": [
|
||||
["d", "999"],
|
||||
["n", "$bob:999"],
|
||||
],
|
||||
"content": "",
|
||||
…
|
||||
```
|
||||
|
||||
Dave announces to generally trust Alice in all things "NIP":
|
||||
|
||||
```
|
||||
"author": $dave,
|
||||
"kind": 40001,
|
||||
"tags": [
|
||||
["n", $alice,
|
||||
],
|
||||
"content": "",
|
||||
…
|
||||
```
|
|
@ -28,6 +28,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
|
|||
- [NIP-27: Text Note References](27.md)
|
||||
- [NIP-28: Public Chat](28.md)
|
||||
- [NIP-33: Parameterized Replaceable Events](33.md)
|
||||
- [NIP-34: Parameterized Versioned Events](34.md)
|
||||
- [NIP-36: Sensitive Content](36.md)
|
||||
- [NIP-39: External Identities in Profiles](39.md)
|
||||
- [NIP-40: Expiration Timestamp](40.md)
|
||||
|
@ -76,6 +77,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
|
|||
| 10000-19999 | Replaceable Events | [16](16.md) |
|
||||
| 20000-29999 | Ephemeral Events | [16](16.md) |
|
||||
| 30000-39999 | Parameterized Replaceable Events | [33](33.md) |
|
||||
| 40000-49999 | Parameterized Versioned Events | [34](34.md) |
|
||||
|
||||
## Message types
|
||||
|
||||
|
|
Loading…
Reference in New Issue
Block a user