NIP-28: Public Chat
The early dream was a Telegram-style public square
NIP-28 came from an early and understandable ambition: if Nostr can replace centralized social timelines, maybe it can also replace public chat channels. The NIP defines channels, channel metadata, messages and basic client-side moderation without asking relays to enforce much policy.
The original motivation says the quiet part out loud: if the protocol solves censorship-resistant social media, it may as well solve Telegram-style messaging too. That was a natural thought in 2022, when Nostr's event model was still expanding and many product surfaces were being tested directly in NIPs.
Today the file begins with a warning: unrecommended, try NIP-29 instead. That does not make NIP-28 useless for a standards archive. It makes it historically important. It shows the first shape of public chat, the reasons it was attractive and the reasons the ecosystem later needed stronger relay-side group semantics.
Five event kinds for channels, messages and client-side moderation
NIP-28 reserves kind 40 for channel creation, kind 41 for channel metadata, kind 42 for channel messages, kind 43 for hiding a message and kind 44 for muting a user. The model is simple: a channel is created by an event, metadata updates refer back to it, and messages use NIP-10-style e tags for root and reply relationships.
Kind 41 metadata can carry name, about, picture and relays. Later updates added category t tags so channels could be searched or filtered by topic. Kind 42 messages carry plain text and tags to identify the channel root and optional reply target.
Moderation is deliberately client-centric. Kind 43 hides a message for a user, with optional reason metadata. Kind 44 mutes a pubkey. Other clients may choose to respect those events more broadly, but relays do not become the central authority of the channel.
Public chat arrived early and then got overtaken
Christopher David added NIP-28 in September 2022 through PR #38, with links to an ArcadeCity chat demo and Telegram discussion. The file then accumulated practical fixes: missing commas, mandatory root event tags, removal of a reserved range and clearer relay recommendations.
In 2024, Vitor Pamplona clarified which relays clients use for NIP-28, and Asai Toshiya simplified kind 41. In January 2025, T. Shinohara added t tags to kind 41. In May 2026, fiatjaf's broader unrecommended-warning pass made the guidance visible in the file body.
The historical arc is clear: NIP-28 was a practical early chat design, but it left too much community authority in clients and too little in relay policy. NIP-29 later took the harder route by making groups relay-based, permissioned and moderation-aware.
Old channels still matter when reading existing clients and archives
NIP-28 was implemented or tracked in several places. Nostrbook's group comparison page describes NIP-28 as a simple public-chat approach and notes use in Amethyst and Iris. The nostr-sdk-ios issue tracker has an open implementation ticket for NIP-28 Public Chat. 0xChat's Dart library lists NIP-28 support.
That means an archive cannot simply delete it. Old chat events, client code and app references still exist. Someone landing on NIP-28 needs to understand both the event kinds and the current guidance away from using it for new community architecture.
The implementation pain comes from moderation and context. If one client hides a message and another does not, the channel state differs. If relay recommendations go stale, the room fragments. If channel metadata is not reliably tied to the creator, clients can display conflicting channel names or pictures.
Public chat needs governance, not only event kinds
NIP-28's weakness is not that the event kinds are confusing. The weakness is that public chat rooms need membership, moderation, permissions, continuity and shared state. Client-side hide and mute events help individual users, but they do not create a coherent group policy.
A new product can still learn from NIP-28. Simple channels are attractive because they are easy to build. Serious communities need the extra complexity that NIP-29 adds: relay-enforced membership, roles, join requests, moderation events and group metadata signed by the relay.
Read NIP-28 in the wild
NIP-28 is the older public-chat-channel model. It is useful history because it shows how Nostr tried to model rooms before newer group, chat and forum standards split the problem into cleaner pieces.
Do not treat it as the only chat answer. If you are evaluating public rooms today, compare it with NIP-29, NIP-C7 and NIP-7D so you know whether you need channels, relay-based groups, chats or forum threads.
What changes when you actually use it
For you, NIP-28: Public Chat 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-29, NIP-10 as the surrounding map before trusting the room label.
What changes for builders and operators
For builders, NIP-28: Public Chat 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 Kind 40: Create channel, Kind 41: Set channel metadata, Kind 42: Create channel message, Kind 43: Hide message, Kind 44: Mute user, Relay recommendations. Inspect kind 40, kind 41, kind 42, kind 43, kind 44, unrecommended, draft, 40 - channel create because these are the pieces most likely to surface as product behavior. Read it beside NIP-29, NIP-10 before treating it as isolated.
NIP-28: Public Chat needs honest audience language. Public, private, group, encrypted, temporary and moderated are different promises.
Where it breaks
The failure mode in NIP-28: Public Chat 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-28: Public Chat 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-28: Public Chat is using one room word for several protocols. Chat, public chat, private DM, group, forum thread, comment and encrypted envelope are different. Read NIP-29, NIP-10 and keep the interface honest about which promise is actually present.
Language that keeps the feature honest
Good product copy for NIP-28: Public Chat 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-28: Public Chat 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-28: Public Chat 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-29, NIP-10 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: nips.nostr.com NIP-28 mirror, Arcade chat demo PR, Nostrbook group comparison, nostr-sdk-ios issue #88. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-28 source is the anchor for exact wording, and NIP-28 commit history shows how that wording moved over time. The strongest secondary clues here are nips.nostr.com NIP-28 mirror, Arcade chat demo PR, Nostrbook group comparison. 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-28: Public Chat: first the human promise, then kind 40, kind 41, kind 42, kind 43, kind 44, unrecommended, then the implementation record, then the real-world failure case. That order keeps NIP-28 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 40,kind 41,kind 42,kind 43,kind 44in the official file and check where the UI exposes the same concept. - Read NIP-29, NIP-10 as context before treating NIP-28 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-28: Public Chat in that order: Official NIP-28 source for the current wording; NIP-28 commit history for the change record; nips.nostr.com NIP-28 mirror, Arcade chat demo PR, Nostrbook group comparison 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.
