diff options
Diffstat (limited to '16.md')
| -rw-r--r-- | 16.md | 35 |
1 files changed, 2 insertions, 33 deletions
| @@ -4,37 +4,6 @@ NIP-16 | |||
| 4 | Event Treatment | 4 | Event Treatment |
| 5 | --------------- | 5 | --------------- |
| 6 | 6 | ||
| 7 | `draft` `optional` `author:Semisol` | 7 | `final` `mandatory` `author:Semisol` |
| 8 | 8 | ||
| 9 | Relays may decide to allow replaceable and/or ephemeral events. | 9 | Moved to [NIP-01](01.md). |
| 10 | |||
| 11 | Regular Events | ||
| 12 | ------------------ | ||
| 13 | A *regular event* is defined as an event with a kind `1000 <= n < 10000`. | ||
| 14 | Upon a regular event being received, the relay SHOULD send it to all clients with a matching filter, and SHOULD store it. New events of the same kind do not affect previous events in any way. | ||
| 15 | |||
| 16 | Replaceable Events | ||
| 17 | ------------------ | ||
| 18 | A *replaceable event* is defined as an event with a kind `10000 <= n < 20000`. | ||
| 19 | Upon a replaceable event with a newer timestamp than the currently known latest replaceable event with the same kind and author being received, the old event SHOULD be discarded, | ||
| 20 | effectively replacing what gets returned when querying for | ||
| 21 | `author:kind` tuples. | ||
| 22 | |||
| 23 | If two events have the same timestamp, the event with the lowest id (first in lexical order) SHOULD be retained, and the other discarded. | ||
| 24 | |||
| 25 | Ephemeral Events | ||
| 26 | ---------------- | ||
| 27 | An *ephemeral event* is defined as an event with a kind `20000 <= n < 30000`. | ||
| 28 | Upon an ephemeral event being received, the relay SHOULD send it to all clients with a matching filter, and MUST NOT store it. | ||
| 29 | |||
| 30 | Client Behavior | ||
| 31 | --------------- | ||
| 32 | |||
| 33 | Clients SHOULD use the `supported_nips` field to learn if a relay supports this NIP. Clients SHOULD NOT send ephemeral events to relays that do not support this NIP; they will most likely be persisted. Clients MAY send 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. | ||
| 34 | |||
| 35 | Suggested Use Cases | ||
| 36 | ------------------- | ||
| 37 | |||
| 38 | * States: An application may create a state event that is replaced every time a new state is set (such as statuses) | ||
| 39 | * Typing indicators: A chat application may use ephemeral events as a typing indicator. | ||
| 40 | * Messaging: Two pubkeys can message over nostr using ephemeral events. | ||