Paso 1 de 5
Añade el tag expiration
El autor elige una marca de tiempo Unix futura y añade ["expiration", "<timestamp>"] antes de firmar. El tag queda cubierto por la firma, así que nadie puede cambiar la fecha después.
NIP-40
Marca de tiempo de expiración
BorradorEventosRelay
Añade un tag expiration para que un evento pueda indicar cuándo deja de ser relevante. Los relays compatibles dejan de servirlo a partir de ese momento y los clientes lo ocultan, algo ideal para avisos temporales y ofertas por tiempo limitado.
De un vistazo
- Estado
- En uso, pero todavía puede cambiar.
- Tags
- expiration
- Último cambio
- 23 dic 2025
Pruébalo
Edita el formulario o el JSON: ambos se mantienen sincronizados, la insignia indica si el resultado es válido y, al tocar cualquier campo, se explica qué hace.
Aún sin firmar · Solo claves de demo. Las claves secretas de estos personajes son públicas a propósito.
Explicación
Selecciona cualquier campo del formulario o del JSON para ver qué hace.
Cómo funciona este NIP
En el curso
Ningún capítulo del curso cubre este NIP todavía. El editor de arriba es la forma más rápida de empezar.
NIPs relacionados
Se basa en
- NIP-11 Documento de información del relay
Los clientes revisan supported_nips en el documento de información del relay antes de usar eventos con expiración.
Amplía
- NIP-01 Descripción del flujo básico del protocolo
Añade un tag opcional al formato básico de evento.
Usado por
Ver también
- NIP-09 Solicitud de borrado de eventos
Las solicitudes de borrado eliminan un evento bajo demanda; la expiración programa su eliminación por adelantado.
Especificación
El texto de las especificaciones se cita en inglés del repositorio nostr-protocol/nips. Nuestras explicaciones y la interfaz están traducidas. Código fuente en GitHub en el commit 0046368
Leer la especificación316 palabras, citadas del repositorio en el commit 0046368.
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.
Spec
tag: expiration
values:
- [UNIX timestamp in seconds]: required
Example
{
"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 SHOULD ignore events that have expired.
Relay Behavior
Relays MAY NOT delete expired messages immediately on expiration and MAY persist them indefinitely. Relays SHOULD NOT send expired events to clients, even if they are stored. Relays SHOULD drop any events that are published to them if they are expired. An expiration timestamp does not affect storage of ephemeral events.
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.
Warning
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.