Nostr NIPS 33


Page content


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.


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":[]: 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.

Source: nostr-protocol/nips/ version: f938923 2023-03-09T13:25:24+00:00