NIP-A4: Public Messages
Sometimes you want a public ping, not a DM thread
Nostr already has several message-like shapes: public notes, old encrypted DMs, NIP-17 private messages, comments, chats and group protocols. NIP-A4 carves out a smaller use case: a simple public plaintext message to one or more users.
The official text is blunt about the boundary. There is no expectation of privacy. Kind 24 is signed and designed for public consumption. It is not a NIP-17 rumor, not a private DM and not a chatroom.
The product use case is notification screens. A client can show a direct public message and let someone reply without reconstructing a long thread or chat history.
Plaintext content and recipient p tags
A kind 24 event puts the message in content and identifies receivers with one or more p tags. Messages must be sent to the NIP-65 inbox relays of each receiver and the outbox relay of the sender.
The NIP deliberately forbids e tags. There is no thread root, no chatroom and no syntactic chain. That keeps the object lightweight, but it also means clients need to not pretend kind 24 is a full conversation model.
Advanced support references several adjacent NIPs: expiration tags from NIP-40, quote repost tags from NIP-18, reactions from NIP-25, zaps from NIP-57, NIP-21 links and NIP-92 media metadata.
Vitor Pamplona added the public-message primitive in late 2025
Vitor Pamplona added Public Messages in December 2025 through PR #1988. fiatjaf later converted examples to YAML style in the broader 2026 cleanup. That short history explains why the NIP reads like a focused product primitive rather than a long security design.
The warning language is the main thing to preserve: anyone can see and reply to messages that may not be for them. The message is addressed, not private.
A good Crays page needs to therefore keep the use case narrow. NIP-A4 is useful when public notification semantics are desired. It is dangerous when users think it hides anything.
The UI needs to say public in the right way
A client needs to render kind 24 near mentions or notifications, not in the main feed by default. It needs to show the addressed recipients and avoid UI language that sounds private.
Expiration tags are recommended because public pings can become stale quickly. A message about meeting now, responding today or reacting to a live context may not make sense months later.
Replies, reactions and zaps needs to include the kind information expected by the NIP so other clients can render them correctly.
Addressed does not mean private
The biggest user risk is confusion. A message can be directed at you and still be public. Clients need to make that obvious at compose time, not only in documentation.
Because anyone can see these messages, spam and harassment filtering will matter if kind 24 adoption grows.
Read NIP-A4 in the wild
NIP-A4 describes public messages. That phrase can sound contradictory if a UI looks like a messenger, so the standard needs plain product language around audience.
A message can be conversational and still public. The client has to show who can read it, where it is stored and whether it belongs in a room, thread or feed.
What changes when you actually use it
For you, NIP-A4: Public Messages is felt inside the room: who can read, who can reply, what remains visible and what the interface makes private by implication. Messaging standards are risky because familiar chat design can smuggle in promises the protocol never made. Read NIP-65, NIP-40, NIP-18, NIP-21, NIP-25 as the surrounding map before trusting the room label.
What changes for builders and operators
For builders, NIP-A4: Public Messages is expectation control. Test the same conversation across relays, devices and clients. Make audience, persistence, encryption and moderation visible. A chat-shaped interface can feel private even when the event is public, and that mismatch is a product bug.
What the official file makes concrete
The official file is organized around Advanced Support, Warnings. Inspect kind 24, draft, .content, p, e, expiration, nevent1, kind because these are the pieces most likely to surface as product behavior. Read it beside NIP-65, NIP-40, NIP-18, NIP-21, NIP-25, NIP-57 before treating it as isolated.
NIP-A4: Public Messages needs honest audience language. Public, private, group, encrypted, temporary and moderated are different promises.
Where it breaks
The failure mode in NIP-A4: Public Messages is false intimacy. The room feels like a messenger, but storage, audience, reply context or metadata tell a more public story. This is where copywriting, UI labels and protocol behavior need to match exactly.
Where this appears outside the markdown
In the ecosystem, NIP-A4: Public Messages touches the most emotionally familiar interface: a conversation. That makes it easy for products to borrow the comfort of chat, groups or DMs while the actual protocol object has different privacy and delivery properties. The page has to slow that moment down before the interface creates a false expectation.
The nearby-standard trap
The nearby-standard trap in NIP-A4: Public Messages is using one room word for several protocols. Chat, public chat, private DM, group, forum thread, comment and encrypted envelope are different. Read NIP-65, NIP-40, NIP-18, NIP-21, NIP-25 and keep the interface honest about which promise is actually present.
Language that keeps the feature honest
Good product copy for NIP-A4: Public Messages names the room. It says public, encrypted, relay-scoped, group-controlled, archived, temporary or moderation-aware when those things are true. It avoids borrowing private-message comfort for data that travels more openly.
What this page does not promise
NIP-A4: Public Messages does not turn every conversation into a private room. A chat-like screen can hide public relays, visible metadata, partial delivery, missing devices or moderation rules that only live on one server. The safe reading is concrete: who can read, where does the event live, what does encryption cover, and what happens when one client leaves?
Read it as a field test
Start NIP-A4: Public Messages with the audience. A message-like interface earns trust only when public, private, encrypted, group-scoped and relay-scoped behavior are not blurred. Read NIP-65, NIP-40, NIP-18, NIP-21, NIP-25 before drawing product conclusions, because most messaging mistakes come from using the wrong room model for the event in front of you.
Where the standard earns trust
The source links give you places to test the interpretation in public: NIP-65 Relay List Metadata, NIP-17 Private Direct Messages, nips.nostr.com NIP-17. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-A4 source is the anchor for exact wording, and NIP-A4 commit history shows how that wording moved over time. The strongest secondary clues here are NIP-65 Relay List Metadata, NIP-17 Private Direct Messages, nips.nostr.com NIP-17. 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-A4: Public Messages: first the human promise, then kind 24, draft, .content, p, e, expiration, then the implementation record, then the real-world failure case. That order keeps NIP-A4 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who can read the event, and does the screen say that before you type?
- What metadata remains visible even when content is encrypted or wrapped?
- Can another client recover the thread, room or message history without pretending delivery is guaranteed?
What to verify before you rely on it
- Find
kind 24,draft,.content,p,ein the official file and check where the UI exposes the same concept. - Read NIP-65, NIP-40, NIP-18, NIP-21, NIP-25 as context before treating NIP-A4 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-A4: Public Messages in that order: Official NIP-A4 source for the current wording; NIP-A4 commit history for the change record; NIP-65 Relay List Metadata, NIP-17 Private Direct Messages, nips.nostr.com NIP-17 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.
