Step 1 of 5
A one-character tag
Add ["-"] to any event. It has no value; its presence alone marks the event as protected.
NIP-70
Protected Events
DraftBehaviourRelay
Adding a ["-"] tag tells relays that only the author may publish this event, so others can't copy it to relays where it wasn't meant to be.
At a glance
- Status
- In use and still allowed to change.
- Tags
- -
- Last changed
- Jun 13, 2026
Try it
Edit the form or the JSON: both stay in sync, the badge says whether the result is valid, and tapping any field explains it.
Not signed yet · Demo keys only. These personas' secret keys are public on purpose.
Explain
Select any field in the form or the JSON to see what it does.
How this NIP works
Who does what
Step 1 of 9
Ready. Press play or step forward to send the first message.
Text version
| # | From | To | Message |
|---|---|---|---|
| 1 | Dave's client | Delta relay | Dave publishes a protected note before authenticating. |
| 2 | Delta relay | Dave's client | The relay asks the client to prove who it is. |
| 3 | Delta relay | Dave's client | Until Dave is authenticated, the protected event is refused. |
| 4 | Dave's client | Delta relay | Dave signs the challenge (NIP-42), proving he controls his pubkey. |
| 5 | Dave's client | Delta relay | Dave resends the same event. |
| 6 | Delta relay | Dave's client | The authenticated pubkey matches the event's author, so it is stored. |
| 7 | Someone else's client | Delta relay | Someone else tries to publish Dave's signed note. |
| 8 | Delta relay | Someone else's client | Their connection isn't authenticated as Dave, so the relay refuses. |
In the course
No course chapter covers this NIP yet. The editor above is the quickest way in.
Related NIPs
Builds on
- NIP-42 Authentication of clients to relays
Relays check authorship with NIP-42 AUTH.
Used by
- NIP-29 Relay-based Groups
Relay-based groups often protect their events this way.
- NIP-43 Relay Access Metadata and Requests
- NIP-EE E2EE Messaging using MLS Protocol
See also
- NIP-18 Reposts
Reposts of protected events must not embed the original.
Specification
Specification text is quoted in English from the nostr-protocol/nips repository. Our explanations and the interface are translated. Source on GitHub at commit 0046368
Read the spec404 words, quoted from the repository at 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.