nips/33.md
Doug Hoyte fe9ed69dc3 Specify replacement behaviour when replaceable events have the same timestamp
- This is so that relays can converge on a deterministic sets of events, no matter the order they were received
- Otherwise, clients or relays that sync their sets of events could continually retransmit events they think are missing on the other side, wasting bandwidth
2023-06-04 18:34:17 -03:00

56 lines
2.9 KiB
Markdown
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

NIP-33
======
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.
Implementation
--------------
The value of a tag can be any string and is defined as the first parameter of a tag after the tag name.
A *parameterized replaceable event* is defined as an event with a kind `30000 <= n < 40000`.
Upon a parameterized replaceable event with a newer timestamp than the currently known latest
replaceable event with the same kind, author and first `d` tag value being received, the old event
SHOULD be discarded, effectively replacing what gets returned when querying for
`author:kind:d-tag` tuples.
If two events have the same timestamp, the event with the lowest id (first in lexical order) SHOULD be retained, and the other discarded.
A missing or a `d` tag with no value should be interpreted equivalent to a `d` tag with the
value as an empty string. Events from the same author with any of the following `tags`
replace each other:
* `"tags":[["d",""]]`
* `"tags":[]`: implicit `d` tag with empty value
* `"tags":[["d"]]`: implicit empty value `""`
* `"tags":[["d",""],["d","not empty"]]`: only first `d` tag is considered
* `"tags":[["d"],["d","some value"]]`: only first `d` tag is considered
* `"tags":[["e"]]`: same as no tags
* `"tags":[["d","","1"]]`: only the first value is considered (`""`)
Clients SHOULD NOT use `d` tags with multiple values and SHOULD include the `d` tag even if it has no value to allow querying using the `#d` filter.
Referencing and tagging
-----------------------
Normally (as per NIP-01, NIP-12) the `"p"` tag is used for referencing public keys and the
`"e"` tag for referencing event ids and the `note`, `npub`, `nprofile` or `nevent` are their
equivalents for event tags (i.e. an `nprofile` is generally translated into a tag
`["p", "<event hex id>", "<relay url>"]`).
To support linking to parameterized replaceable events, the `naddr` code is introduced on
NIP-19. It includes the public key of the event author and the `d` tag (and relays) such that
the referenced combination of public key and `d` tag can be found.
The equivalent in `tags` to the `naddr` code is the tag `"a"`, comprised of `["a", "<kind>:<pubkey>:<d-identifier>", "<relay url>"]`.
Client Behavior
---------------
Clients SHOULD use the `supported_nips` field to learn if a relay supports this NIP.
Clients MAY send parameterized replaceable events to relays that may not support this NIP, and clients querying SHOULD be prepared for the relay to send multiple events and should use the latest one and are recommended to send a `#d` tag filter. Clients should account for the fact that missing `d` tags or ones with no value are not returned in tag filters, and are recommended to always include a `d` tag with a value.