NIP-C7: Chats
A chat stream needs a smaller object than a channel system
Nostr has had public chat channels through NIP-28 and group/community work through NIP-29. NIP-C7 is much smaller: a chat message is kind 9, and a reply to a chat message is another kind 9 that quotes the parent with a q tag.
The goal is ordered chat display. A client rendering a chat view needs to fetch only kind 9 events, which prevents missing context when different clients mix other content types into the same view.
The simplicity is the appeal. NIP-C7 is not an encrypted messenger, not a server-managed chatroom and not a full group-governance model.
Kind 9 messages and q-tag replies
The base event is kind 9 with message text in content. A reply uses another kind 9 and quotes the parent using a q tag, following the quote pattern from NIP-18.
Other content types may be quoted inside a kind 9 event, but the actual chat stream needs to remain kind 9. That lets chat clients avoid loading a mixed feed and then discovering that half the context is missing.
The NIP is tiny, but the rule is important: keep the chat timeline made of chat messages.
hodlbod split chats and threads out from NIP-29
hodlbod broke chats and threads out from NIP-29 in November 2024 through PR #1591. In May 2026, hodlbod updated C7 so chat views only allow kind 9 messages, tightening the implementation guidance.
That origin explains the relationship with NIP-7D forum threads and group work. C7 is one discussion primitive extracted from a larger social system.
Do not confuse it with NIP-28, which is now unrecommended public chat channels using kinds 40-44. C7 is a later, smaller chat-message shape.
Chat clients need to avoid mixed-kind timelines
A chat UI needs to query kind 9 events for the stream, render q-tag replies clearly and allow quoted external content without making that external content part of the chat timeline.
If a client wants encryption, membership, moderation or private groups, it needs other standards. C7 does not solve those problems.
The main product benefit is predictable rendering: several clients can show the same ordered chat without inventing channel semantics.
Small chat standards can look more complete than they are
Kind 9 messages are public unless another system wraps or restricts them. A chat-shaped interface can make public text feel more private than it is.
Spam and moderation also remain external. C7 gives the message object, not the community policy.
Read NIP-C7 in the wild
NIP-C7 gives chats a lightweight public message stream built around kind 9 and q-tag replies. It is smaller than a channel system and clearer than mixing every conversational object into one timeline.
The danger is emotional mismatch. A chat interface feels intimate, but C7 does not automatically mean private, moderated, delivered or erasable. The product has to say what kind of room you are in.
What changes when you actually use it
For you, NIP-C7: Chats 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-01 and the adjacent source links as the surrounding map before trusting the room label.
What changes for builders and operators
For builders, NIP-C7: Chats 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
Inspect kind 9, draft because these are the pieces most likely to surface as product behavior.
NIP-C7: Chats needs honest audience language. Public, private, group, encrypted, temporary and moderated are different promises.
Where it breaks
The failure mode in NIP-C7: Chats 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-C7: Chats 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-C7: Chats is using one room word for several protocols. Chat, public chat, private DM, group, forum thread, comment and encrypted envelope are different. Read NIP-01 and the adjacent source links and keep the interface honest about which promise is actually present.
Language that keeps the feature honest
Good product copy for NIP-C7: Chats 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-C7: Chats 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-C7: Chats 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-01 and the adjacent source links 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-C7, PR #1591, PR #2310, NIP-18 Reposts. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-C7 source is the anchor for exact wording, and NIP-C7 commit history shows how that wording moved over time. The strongest secondary clues here are nips.nostr.com NIP-C7, PR #1591, PR #2310. 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-C7: Chats: first the human promise, then kind 9, draft, then the implementation record, then the real-world failure case. That order keeps NIP-C7 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 9,draftin the official file and check where the UI exposes the same concept. - Read NIP-01 and the adjacent source links as context before treating NIP-C7 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-C7: Chats in that order: Official NIP-C7 source for the current wording; NIP-C7 commit history for the change record; nips.nostr.com NIP-C7, PR #1591, PR #2310 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.
