NIP-40
======

Expiration Timestamp
-----------------------------------

`draft` `optional` `author:0xtlt`

The `expiration` tag enables users to specify a timestamp at UTC-0 at which the message should be considered expired and deleted by relays (or just ignored by clients). This can be useful for making temporary announcements, making limited-time offers, or sending ephemeral messages but should not be seen as a security solution for the content of your messages.
So be careful when sharing confidential information.

#### Spec

```
tag: expiration
options:
 - [UNIX timestamp in seconds]: required
```

#### Example

```json
{
    "pubkey": "<pub-key>",
    "created_at": 1000000000,
    "kind": 1,
    "tags": [
      ["expiration", "1600000000"]
    ],
    "content": "This message will expire at the specified timestamp and be deleted by relays.\n",
    "id": "<event-id>"
}
```

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.

Client Behavior
---------------

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.

Clients MUST ignore events that have expired.

Suggested Use Cases
-------------------

* 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.
* 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.

#### One last time, be careful!
The events could be downloaded by third parties as they are publicly accessible all the time on the relays.
So don't consider expiring messages as a security feature for your conversations or other uses.