{"id":"eeb87b36c659aca5efe7b6d519925d2f5fcd31bebab8be154665e3d3b290b342","pubkey":"fc7085c383ba71745704bdc1c6efcf7fab0197501de598c5e6c537ac0b32a4cb","created_at":1781888740,"kind":30817,"tags":[["d","tag-defined-event-behavior"],["title","Tag-Defined Event Behavior"],["alt","Nostr Implementation Possibility: Tag-Defined Event Behavior"],["client","NostrHub"]],"content":"# Tag-Defined Event Behavior\n\nThis spec expands which events are considered replaceable, addressable, or\nephemeral beyond the event kind ranges defined in NIP-01.\n\nIn this spec, the `d` tag is treated as a deduplication tag. Its value determines\nwhether the event is replaceable or addressable.\n\nSimilarly, a NIP-40 `expiration` tag whose value matches the event's\n`created_at` timestamp marks the event as ephemeral.\n\n## Deduplication-Defined Replaceable Events\n\nEvents with the first `d` tag set to an empty string are considered replaceable\nevents. They are unique by the combination of their `kind` and `pubkey` values.\n\nExample:\n\n```js\n{\n  \"kind\": 999,\n  \"pubkey\": \"f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca\",\n  \"tags\": [\n    [\"d\", \"\"],\n    ...otherTags\n  ]\n  ...otherEventFields\n}\n```\n\n## Deduplication-Defined Addressable Events\n\nEvents with the first `d` tag set to any value other than the empty string are\nconsidered addressable events. They are unique by the combination of their\n`kind`, `pubkey`, and `d` tag values.\n\nExample:\n\n```js\n{\n  \"kind\": 999,\n  \"pubkey\": \"f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca\",\n  \"tags\": [\n    [\"d\", \"example\"],\n    ...otherTags\n  ]\n  ...otherEventFields\n}\n```\n\n## Expiration-Defined Ephemeral Events\n\nEvents with a NIP-40 `expiration` tag set to the same value as their own\n`created_at` field are considered ephemeral events. Relays SHOULD broadcast them\nto clients with matching subscriptions and are not expected to persist them in\ntheir databases.\n\nWhen deciding whether such an event is already expired, relays SHOULD allow a\nsmall clock skew before checking the `expiration` tag value (e.g. by adding 60\nseconds to the expiration timestamp). Relays SHOULD NOT broadcast these events\nafter that clock-skew window has passed.\n\nExample:\n\n```js\n{\n  \"tags\": [\n    [\"expiration\", \"1600000000\"],\n    ...otherTags\n  ],\n  \"created_at\": 1600000000,\n  ...otherEventFields\n}\n```\n\n## Motivation\n\nWithout this mechanism, \"editing\" a regular event means issuing a `kind:5` Event\nDeletion Request that references the event to be deleted and creating a new event\nwith edited content or tags to replace the deleted one. The problem is that\n`kind:5` events are permanent tombstones that can bloat relay databases if used\nto mimic an edit feature. Relying on the `d` tag for edits solves this problem\nfor all events with kinds outside the ranges defined for replaceable or\naddressable events.\n\nMatching the `expiration` tag to the `created_at` timestamp is enough to mark an\nevent as ephemeral.\n\nThe existing NIP-01 kind ranges SHOULD continue to be supported by relays for\nlegacy reasons.","sig":"3f0e0dfd7dd117fc335848c72e1a417e02b25c89cbd229fdddcabc2935abeedf25754a62969f13a127e75881b906fdf93d6c057f10ae02e171fd46fa1cb21fc8"}