diff options
| author | Leo Wandersleb <leo@leowandersleb.de> | 2022-12-16 11:09:26 -0300 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-12-16 11:09:26 -0300 |
| commit | ba75c1b98b64c1f3d502f643e524620c2457141d (patch) | |
| tree | 78aa27ecda9aceb8911a705cf6427ea048da1b9f | |
| parent | 5ef3b9c9985018ceb4aba28e775ea8c621471c17 (diff) | |
| parent | 04a84aa5453ddce1dadcefba331fb1657447d600 (diff) | |
Merge pull request #87 from 0xtlt/master
| -rw-r--r-- | 40.md | 59 |
1 files changed, 59 insertions, 0 deletions
| @@ -0,0 +1,59 @@ | |||
| 1 | NIP-40 | ||
| 2 | ====== | ||
| 3 | |||
| 4 | Expiration Timestamp | ||
| 5 | ----------------------------------- | ||
| 6 | |||
| 7 | `draft` `optional` `author:0xtlt` | ||
| 8 | |||
| 9 | The `expiration` tag enables users to specify a unix timestamp at which the message SHOULD be considered expired (by relays and clients) and SHOULD be deleted by relays. | ||
| 10 | |||
| 11 | #### Spec | ||
| 12 | |||
| 13 | ``` | ||
| 14 | tag: expiration | ||
| 15 | values: | ||
| 16 | - [UNIX timestamp in seconds]: required | ||
| 17 | ``` | ||
| 18 | |||
| 19 | #### Example | ||
| 20 | |||
| 21 | ```json | ||
| 22 | { | ||
| 23 | "pubkey": "<pub-key>", | ||
| 24 | "created_at": 1000000000, | ||
| 25 | "kind": 1, | ||
| 26 | "tags": [ | ||
| 27 | ["expiration", "1600000000"] | ||
| 28 | ], | ||
| 29 | "content": "This message will expire at the specified timestamp and be deleted by relays.\n", | ||
| 30 | "id": "<event-id>" | ||
| 31 | } | ||
| 32 | ``` | ||
| 33 | |||
| 34 | Note: The timestamp should be in the same format as the created_at timestamp and should be interpreted as the time at which the message should be deleted by relays. | ||
| 35 | |||
| 36 | Client Behavior | ||
| 37 | --------------- | ||
| 38 | |||
| 39 | Clients SHOULD use the `supported_nips` field to learn if a relay supports this NIP. Clients SHOULD NOT send expiration events to relays that do not support this NIP. | ||
| 40 | |||
| 41 | Clients SHOULD ignore events that have expired. | ||
| 42 | |||
| 43 | Relay Behavior | ||
| 44 | -------------- | ||
| 45 | |||
| 46 | Relays MAY NOT delete an expired message immediately on expiration and MAY persist them indefinitely. | ||
| 47 | Relays SHOULD NOT send expired events to clients, even if they are stored. | ||
| 48 | Relays SHOULD drop any events that are published to them if they are expired. | ||
| 49 | An expiration timestamp does not affect storage of ephemeral events. | ||
| 50 | |||
| 51 | Suggested Use Cases | ||
| 52 | ------------------- | ||
| 53 | |||
| 54 | * Temporary announcements - This tag can be used to make temporary announcements. For example, an event organizer could use this tag to post announcements about an upcoming event. | ||
| 55 | * Limited-time offers - This tag can be used by businesses to make limited-time offers that expire after a certain amount of time. For example, a business could use this tag to make a special offer that is only available for a limited time. | ||
| 56 | |||
| 57 | #### Warning | ||
| 58 | The events could be downloaded by third parties as they are publicly accessible all the time on the relays. | ||
| 59 | So don't consider expiring messages as a security feature for your conversations or other uses. | ||