NIP-70: Protected Events
Not every public event is meant to be syndicated everywhere
Nostr events are easy to copy between relays. That is usually a feature. It becomes a problem when an author wants a semi-closed relay, private community or controlled distribution context. NIP-70 gives authors and relays a small signal for that case.
The tag is just ["-"]. When present, the event is protected. A relay that supports the NIP needs to only accept it after NIP-42 authentication proves the publisher is the event author. A relay that does not support protected events must reject them by default.
This does not make information impossible to copy. It makes compliant relays refuse to help copy it.
One tag and a strict relay rule
The protected tag can be added to any event. Relays accepting it must require AUTH, compare the authenticated pubkey to the event pubkey and reject if they do not match. The example flow shows a relay first returning auth-required, then accepting after the client authenticates.
Reposts of protected events must not embed the reposted event. If a repost embeds a protected event anyway, relays needs to reject it. That rule matters because embedding would leak the protected content into a new event even if the original relay policy was respected.
NIP-70 is therefore a relay-enforced publication control, not encryption and not deletion.
A small access-control NIP that later tightened reposts
fiatjaf added the visible relay-based event access-control work in July 2024. In May 2026, PR #2251 clarified that reposts embedding protected events must be rejected. The June 2026 formatting cleanup touched the file with the rest of the repo.
The NIP is short because the idea is intentionally narrow. It composes with NIP-42 authentication and relay policy rather than creating a new private-message protocol.
Its real importance appears in communities and restricted relays, where the author wants public-format events without universal rebroadcast assistance.
Protected means relay-respected, not secret
A relay implementing NIP-70 needs to reject protected events by default unless the authenticated user is the event author. A client needs to understand auth-required and retry after NIP-42 if the user wants to publish there.
A user-facing UI must not say private. The event content may still be readable by authorized relay people and can still be copied by people who saw it. Protected means compliant relays must not accept third-party publishing or embedded repost leakage.
This works best when paired with private or community relays that have clear access policy.
The word protected can mislead users
The biggest risk is user misunderstanding. Protected events can still be read and copied by parties that receive them. The NIP limits relay acceptance behavior, not human behavior.
Relays also need strict defaults. If a relay accepts protected events without auth, it breaks the author's expectation and teaches clients the wrong pattern.
Read NIP-70 in the wild
NIP-70 marks protected events. It gives authors a way to signal that an event is not meant for casual redistribution or broad indexing.
This is social protocol, not hard DRM. A tag cannot stop someone from copying data they already received. It can only help responsible clients honor the boundary.
What changes when you actually use it
For you, NIP-70: Protected Events is felt when an app either behaves predictably or suddenly loses context. The visible symptom may be a missing reply, a broken link, a strange reaction count, an empty result or a relay error that looks like the whole network failed. The official terms draft, relay, AUTH are where that visible behavior begins, so the source is not background material; it is the place where the product promise gets its limits.
What changes for builders and operators
For builders, NIP-70: Protected Events is compatibility discipline. Implement draft, relay, AUTH against more than one relay and more than one library, then test malformed, missing and duplicated data. Core standards fail most painfully when the happy path looks fine and the second client exposes the shortcut.
What the official file makes concrete
The official file is organized around The tag, Example flow, Why. Inspect draft, relay, AUTH because these are the pieces most likely to surface as product behavior. Read it beside NIP-42 before treating it as isolated.
NIP-70: Protected Events is a shared contract between independent software. The smallest field can become user-visible when two clients disagree about it.
Where it breaks
The failure mode in NIP-70: Protected Events is often indirect. Nobody complains about draft, relay, AUTH; they complain that the feed is wrong, the reply vanished or the relay behaved strangely. Use the official file to diagnose the hidden cause instead of patching only the visual symptom.
Where this appears outside the markdown
In the ecosystem, NIP-70: Protected Events is not something most people choose directly. It is the invisible grammar behind clients, relays, crawlers, search tools and archives. When a product team treats draft, relay, AUTH as implementation detail only, the mistake eventually reaches the surface as missing history, bad threading or state that cannot be reconstructed after a client switch.
The nearby-standard trap
The nearby-standard trap in NIP-70: Protected Events is assuming the base layer solves the higher-level feature. This NIP may define the common grammar, but publishing, wallets, moderation, media or groups still need their own constraints. Read NIP-42 to see where the base contract ends and the product-specific promise begins.
Language that keeps the feature honest
Good product copy for NIP-70: Protected Events does not say "the protocol handles it" and move on. It explains the visible consequence: what was sent, what was accepted, what was rejected, what is still loading and what another relay or client may show differently.
What this page does not promise
NIP-70: Protected Events does not promise a finished social product. It gives software a shared grammar. Feed design, moderation, ranking, notifications, storage duration and recovery remain separate product decisions. That distinction matters because a client can be technically compatible and still give you a weak experience if it hides relay errors, drops context or treats optional fields as if every app understood them.
Read it as a field test
Start NIP-70: Protected Events with the visible product symptom, then trace it back to draft, relay, AUTH. That order keeps the article grounded: you see why the field exists, which relay or client behavior depends on it, and where adjacent standards change the story. A core NIP is strong only when it explains both the normal path and the awkward edge case.
Where the standard earns trust
The source links give you places to test the interpretation in public: NIP-42 Authentication, NIP-18 Reposts, PR #2251. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-70 source is the anchor for exact wording, and NIP-70 commit history shows how that wording moved over time. The strongest secondary clues here are NIP-42 Authentication, NIP-18 Reposts, PR #2251. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-70: Protected Events: first the human promise, then draft, relay, AUTH, then the implementation record, then the real-world failure case. That order keeps NIP-70 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can two independent clients read the same
draft,relay,AUTHwithout a hidden compatibility rule? - Does the UI explain relay rejection, missing context or state replacement without blaming the whole network?
- Which adjacent standard, especially NIP-42, changes the behavior once the base event leaves the happy path?
What to verify before you rely on it
- Find
draft,relay,AUTHin the official file and check where the UI exposes the same concept. - Read NIP-42 as context before treating NIP-70 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-70: Protected Events in that order: Official NIP-70 source for the current wording; NIP-70 commit history for the change record; NIP-42 Authentication, NIP-18 Reposts, PR #2251 for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
