NIP-A4: Public Messages
NIP-A4 defines kind 24 as a plaintext public message addressed to one or more users, meant for notification-style replies rather than feeds, private DMs or persistent chat threads.
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 should 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 should 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 should say public in the right way
A client should render kind 24 near mentions or notifications, not in the main feed by default. It should 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 should 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.
Direct sources
Use the official file first, then the commit history, implementation references and adjacent standards. NIPs move, and product guidance gets weaker when those source trails are hidden.
