Research Source: NIP-28: Public Chat
Crays deep-research source page for NIP-28: Public Chat, based on the Nostr research workbook and live URL audit.
NIP-28: Public Chat is part of the Crays Nostr deep research database. This page turns the workbook entry and live source audit into a readable archive chapter.
What the NIP covers
NIP-28: Public Chat is part of the standards route, so read it as an interoperability contract rather than a product announcement. The workbook places it in Chat and Standards / NIPs, with the subcategory Chat and Unrecommended, and the source status is reachable during audit, HTTP 200.
The workbook note gives the first signal: Status: Unrecommended. Try NIP-29 groups. Try NIP-29 groups. That note is not enough on its own; the useful work is to connect it to events, clients, relays, wallets, signers, media or governance behavior.
A NIP page should answer three practical questions: which object or flow is being standardized, which actors must implement it, and what breaks when support is partial or inconsistent.
- Category. Chat and Standards / NIPs
- Subcategory. Chat and Unrecommended
- Importance. High and Unrecommended
Plain-language interpretation
If you are not implementing the specification, the simple question is: what new user-facing behavior does NIP-28: Public Chat make possible? A good answer avoids raw standards language first and explains the effect: safer signing, clearer identity, better relay routing, media portability, wallet interaction, moderation signal, discovery, or another product consequence.
NIPs are optional conventions in an open ecosystem. They become real only when clients, relays, wallets or services implement them well enough that users can trust the behavior.
Data model, actors and responsibilities
The captured source structure points toward Navigation Menu, Search code, repositories, users, issues, pull requests..., Provide feedback, Saved searches, Use saved searches to filter your results more quickly and Files Expand file tree. Use that as evidence, then translate the shape into a clear actor map.
The actor map should name who signs, who stores, who reads, who verifies, who pays, who moderates and who has to provide a fallback. For many NIPs the same event looks simple, but the responsibility is split across client UX, relay policy, wallet permissions, signer prompts and indexing behavior.
That split is why standards pages need more than definitions. They need implementation pressure: what must be stable, what may vary and what the reader should not assume from the NIP number alone.
Implementation questions
Before we treat NIP-28: Public Chat as ready for a product path, the page should ask whether current clients support it, whether relays preserve the relevant events, whether the security model is clear and whether the user can understand the prompt or action.
A weak implementation can make a good NIP feel broken. A strong implementation hides enough detail to be usable while keeping the ownership, consent and portability boundaries visible.
- Client support. Which clients expose the behavior and how mature is the interface?
- Relay behavior. Do relays store, filter, count, authenticate or reject the relevant event flow?
- User safety. Can a user understand what they are signing, publishing, authorizing or paying?
Common failure modes
The common failure mode is treating a NIP as a guarantee. A NIP can describe the shape; it cannot force every client to support it, every relay to store it, every wallet to approve it or every app to explain it well.
For NIP-28: Public Chat, the page should watch for partial support, stale source links, confusing prompts, privacy leakage, weak fallback behavior and claims that sound stronger than the current ecosystem evidence.
Workbook evidence
This source appears in 2 workbook reference row(s). Keep those rows visible because the same NIP can appear as standards evidence, product evidence, security evidence or developer-stack evidence depending on the sheet.
Source trail and next reading
The source URL is https://github.com/nostr-protocol/nips/blob/master/28.md. Use it as the canonical or workbook-backed evidence point, then continue into the NIP explainer route, the related product route and the practical article that shows what the standard changes for a reader.
The right next step is not a generic pile of tabs. It is the neighboring concept that explains the consequence: identity, relay routing, signing, wallet access, media storage, discovery, moderation, governance or commerce.
How to place Research Source: NIP-28: Public Chat on the map
Read Research Source: NIP-28: Public Chat as part of the Library route, not as an isolated entry. Its main surface is research and archive navigation: source maps, deep research, glossary entries, long reads, indexes, field guides and routes through the archive. That framing matters because a Nostr page is useful only when you can see which layer it belongs to and which layer it does not solve by itself.
The first question is practical: what changes for you if Research Source: NIP-28: Public Chat works well? Sometimes the answer is safer signing, sometimes better relay discovery, sometimes clearer media storage, sometimes a stronger source trail. Keep that question in front of you and the page becomes easier to judge.
- Layer. Library is the parent route, so the page should send you back to that shelf and sideways into adjacent concepts.
- Evidence. The current source trail starts with NIP-28: Public Chat, nips.nostr.com, Nostr protocol repository, Nostr NIPs. Treat those as anchors, then compare product behavior and NIP support.
What Research Source: NIP-28: Public Chat should help you decide
A good page about Research Source: NIP-28: Public Chat should leave you with a decision, not just recognition. You should know whether it is a protocol primitive, a client behavior, a relay operation, a product example, a research source or our implementation question. That distinction keeps the archive from becoming a flat glossary.
The common mistake is leaving the reader with a flat pile of links instead of a guided path through sources, concepts and examples. We avoid that by making the claim, the evidence and the next step visible. If a statement depends on a NIP, the page should point to that NIP. If it depends on a project, the page should show the project source. If it affects user safety, the page should say what can fail.
The working example behind Research Source: NIP-28: Public Chat
Use this page with a concrete mental test: a library page should tell you what kind of source you are looking at, what to trust, what to verify and where it fits in the wider map. That example is more useful than a generic definition because Nostr is not one product. The same signed event can be read by different clients, stored by different relays and interpreted through different product choices.
This is also why internal links matter. When the page mentions keys, clients, relays, events, zaps, Blossom, Cashu, FoundUPS or NIPs, those words should lead to the page that explains the concept more deeply. The goal is not to trap you in tabs; the goal is to let you move with context.
Source discipline for Research Source: NIP-28: Public Chat
The source list is part of the content, not decoration. For Research Source: NIP-28: Public Chat, use primary protocol documents first when the claim is technical, project repositories or product pages when the claim is about an app, and research or directory sources when the claim is about ecosystem position. If the sources disagree, the page should show the uncertainty instead of smoothing it away.
That source discipline is how a large archive stays trustworthy. It also helps learning: you get a short explanation first, then a route to the source that proves or complicates it. The page should feel like a guided chapter, but the evidence should still be close enough to inspect.
Before and after reading Research Source: NIP-28: Public Chat
Before reading Research Source: NIP-28: Public Chat, make sure you know the nearby base concepts: a public key identifies, a private key signs, relays carry signed events, clients render those events, and NIPs describe shared behavior. You do not need to memorize the whole protocol, but those pieces prevent most confusion.
After reading Research Source: NIP-28: Public Chat, the next useful move is to compare it with one neighboring page. If this is an app, compare it with a signer, relay or wallet page. If this is a NIP, compare it with the product behavior it enables. If this is a research source, compare it with the hub that uses it. That is how the archive becomes a learning path instead of a pile.