Nostr NIPS 33
Parameterized Replaceable Events
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.
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
replace each other:
dtag with empty value
"tags":[["d"]]: implicit empty value
"tags":[["d",""],["d","not empty"]]: only first
dtag is considered
"tags":[["d"],["d","some value"]]: only first
dtag 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
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
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>"].
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.
Source: nostr-protocol/nips/33.md version: f938923 2023-03-09T13:25:24+00:00