2.7 KiB
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 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 and first d
tag value being received, the old event
SHOULD be discarded and replaced with the newer event.
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":[]
: implicitd
tag with empty value"tags":[["d"]]
: implicit empty value""
"tags":[["d",""],["d","not empty"]]
: only firstd
tag is considered"tags":[["d"],["d","some value"]]
: only firstd
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.