Paso 1 de 5
Un tag de un solo carácter
Añade ["-"] a cualquier evento. No tiene valor; su sola presencia marca el evento como protegido.
NIP-70
Eventos protegidos
BorradorComportamientoRelay
Añadir un tag ["-"] indica a los relays que solo el autor puede publicar este evento, para que otros no lo copien a relays donde no debía estar.
De un vistazo
- Estado
- En uso, pero todavía puede cambiar.
- Tags
- -
- Último cambio
- 13 jun 2026
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
Quién hace qué
Paso 1 de 9
Listo. Presiona reproducir o avanza un paso para enviar el primer mensaje.
Versión en texto
| # | De | Para | Mensaje |
|---|---|---|---|
| 1 | Cliente de Dave | Relay Delta | Dave publica una nota protegida antes de autenticarse. |
| 2 | Relay Delta | Cliente de Dave | El relay pide al cliente que demuestre quién es. |
| 3 | Relay Delta | Cliente de Dave | Hasta que Dave se autentique, el evento protegido se rechaza. |
| 4 | Cliente de Dave | Relay Delta | Dave firma el desafío (NIP-42), demostrando que controla su pubkey. |
| 5 | Cliente de Dave | Relay Delta | Dave reenvía el mismo evento. |
| 6 | Relay Delta | Cliente de Dave | La pubkey autenticada coincide con el autor del evento, así que se almacena. |
| 7 | Cliente de otra persona | Relay Delta | Otra persona intenta publicar la nota firmada de Dave. |
| 8 | Relay Delta | Cliente de otra persona | Su conexión no está autenticada como Dave, así que el relay la rechaza. |
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-42 Autenticación de clientes ante relays
Los relays comprueban la autoría con AUTH de NIP-42.
Usado por
- NIP-29 Grupos basados en relays
Los grupos basados en relays suelen proteger así sus eventos.
- NIP-43 Metadatos y solicitudes de acceso a relays
- NIP-EE Mensajería E2EE con el protocolo MLS
Ver también
- NIP-18 Reposts
Los reposts de eventos protegidos no deben incrustar el original.
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ón404 palabras, citadas del repositorio en el commit 0046368.
When the "-" tag is present, that means the event is "protected".
A protected event is an event that can only be published to relays by its author. This is achieved by relays ensuring that the author is authenticated before publishing their own events or by just rejecting events with ["-"] outright.
The default behavior of a relay MUST be to reject any event that contains ["-"].
Relays that want to accept such events MUST first require that the client perform the NIP-42 AUTH flow and then check if the authenticated client has the same pubkey as the event being published and only accept the event in that case.
Reposts of protected events MUST NOT embed the reposted event. If a repost of a protected event embeds the event anyway, relays SHOULD summarily reject it.
The tag
The tag is a simple tag with a single item: ["-"]. It may be added to any event.
Example flow
- User
79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798connects to relaywss://example.com:
/* client: */
["EVENT",{"id":"cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2","pubkey":"79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798","created_at":1707409439,"kind":1,"tags":[["-"]],"content":"hello members of the secret group","sig":"fa163f5cfb75d77d9b6269011872ee22b34fb48d23251e9879bb1e4ccbdd8aaaf4b6dc5f5084a65ef42c52fbcde8f3178bac3ba207de827ec513a6aa39fa684c"}]
/* relay: */
["AUTH", "<challenge>"]
["OK", "cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2", false, "auth-required: this event may only be published by its author"]
/* client: */
["AUTH", {}]
["EVENT",{"id":"cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2","pubkey":"79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798","created_at":1707409439,"kind":1,"tags":[["-"]],"content":"hello members of the secret group","sig":"fa163f5cfb75d77d9b6269011872ee22b34fb48d23251e9879bb1e4ccbdd8aaaf4b6dc5f5084a65ef42c52fbcde8f3178bac3ba207de827ec513a6aa39fa684c"}]
["OK", "cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2", true, ""]
Why
There are multiple circumstances in which it would be beneficial to prevent the unlimited spreading of an event through all relays imaginable and restrict some to only a certain demographic or to a semi-closed community relay. Even when the information is public it may make sense to keep it compartimentalized across different relays.
It's also possible to create closed access feeds with this when the publisher has some relationship with the relay and trusts the relay to not release their published events to anyone.
Even though it's ultimately impossible to restrict the spread of information on the internet (for example, one of the members of the closed group may want to take an event intended to be restricted and republish it to other relays), most relays would be happy to not facilitate the acts of these so-called "pirates", in respect to the original decision of the author and therefore gladly reject these republish acts if given the means to.
This NIP gives these authors and relays the means to clearly signal when a given event is not intended to be republished by third parties.