Research Reading Path
A route for careful analysis: primary standards, empirical relay data, source triangulation, client claims, NIP drift, directories and our product relevance.
This path is for research mode. You are not trying to collect links. You are trying to know which claims are standards, which are product choices, which are cultural beliefs and which are still untested.
Separate source types first
A NIP, a client website, a GitHub README, a relay monitor, a directory listing, a blog essay and an academic measurement paper all answer different questions. Mixing them creates fake certainty.
Use primary standards for what software may implement. Use repos for what code appears to do. Use monitors for live infrastructure clues. Use essays for framing. Use empirical papers for measured trade-offs and limitations.
Use NIPs as moving standards, not scripture
The NIPs repository itself says the documents describe what may be implemented by compatible relay and client software. That means a NIP can be optional, draft, final, mandatory or unrecommended. A product's support for a NIP is evidence, not a guarantee of quality.
Track status and adoption separately. NIP-01 is foundational. NIP-05 and NIP-19 are highly practical. NIP-96 is useful historically but now points you toward Blossom for newer file storage thinking.
Measure relay claims against reality
Relay pages can advertise features through NIP-11. Relay monitors can show liveness, latency and discovered URLs. Academic work can show broader patterns such as availability, replication overhead and decentralization limits. None of those views is complete alone.
When a relay matters to a product, test it directly. Publish, query, authenticate, inspect OK and CLOSED messages, check retention, simulate downtime and compare behavior across clients.
Audit clients by behavior
Client claims should be tested through actions: key handling, signer support, relay list behavior, profile fetching, media rendering, search, wallet prompts, moderation controls and export paths. A beautiful UI can still make dangerous key choices.
The most useful research notes are concrete. Which signer did it use? Which event kinds did it publish? Which relays did it read? What broke in a second client? What warning did the user see?
Watch the media-storage shift
File storage is a good example of Nostr drift. NIP-96 described HTTP file storage integration, but the current NIPs index marks it unrecommended in favor of Blossom. Blossom uses HTTP servers, sha256-addressed blobs, Nostr keys and BUD documents.
A research page should not freeze the ecosystem at the first standard it finds. It should explain the path: why media cannot simply live inside ordinary relays, what NIP-94 describes, why NIP-96 mattered and why Blossom became important.
Build a repeatable note format
For every important source, capture the same fields: source type, owner, URL, last checked date, claim, evidence, relevant NIPs, product risk, Why it matters to us and open questions. That turns research from browsing into a usable operating memory.
The Excel workbook already points in this direction by separating NIPs, clients, developer stack, relays, reads and directories. The next level is page-specific synthesis: not just where the link points, but what decision it helps you make.
- Claim. What is being asserted?
- Evidence. Where can we verify it?
- Adoption. Who actually implements it?
- Risk. What breaks if the claim is wrong?
- Product use. How does this affect Crays, venues, commerce or governance?
End with a decision, not a folder
Research should change judgment. After reading, you should know whether a topic is ready for product use, needs a prototype, belongs in the library, needs monitoring or should be avoided for now.
That is how we keep a 1400-plus page archive useful. Every page should help you decide what to trust, what to test and what to read next.
A claim taxonomy for every page
Mark each claim as one of five types: standard claim, implementation claim, measurement claim, cultural claim or our product claim. A standard claim needs a NIP. An implementation claim needs a repo or live product. A measurement claim needs data. A cultural claim needs context. A product claim needs our own architecture or roadmap logic.
This taxonomy prevents weak writing. It forces every paragraph to know what kind of truth it is trying to tell.
How to research a NIP without fooling yourself
Read the NIP status, scope and examples. Check whether major clients or libraries implement it. Look for adjacent or superseding NIPs. Then test a small event yourself if the topic is important. Do not infer adoption from existence.
NIP-96 is the perfect warning: it exists, it is useful history, but the NIP table now marks it unrecommended in favor of Blossom. A shallow article would miss that shift.
How to research relays
Use NIP-11 documents, relay monitors, direct publish/read tests and software repositories together. Relay discovery pages tell you what is visible. Direct tests tell you what happens to your events. Repositories tell you what the operator could be running, not necessarily how it is configured.
How to research clients
For a client, record platforms, login method, signer support, supported event kinds, relay strategy, wallet flow, media handling, moderation controls, export or migration behavior, visible maintenance and whether data remains legible in other clients.
The output of good research
Good research should produce a decision: explain, prototype, monitor, adopt, avoid or archive. A page that only says this exists is not enough. A page should tell you whether the thing is mature, risky, misunderstood, strategically relevant or mainly useful as background.
How to place Research Reading Path on the map
Read Research Reading Path as part of the Start route, not as an isolated entry. Its main surface is first-principles learning: keys, clients, relays, events and the first safe mental model. 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 Reading Path 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. Start 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 Nostr protocol repository, Nostr NIPs, nostr.how, nostr.com. Treat those as anchors, then compare product behavior and NIP support.
What Research Reading Path should help you decide
A good page about Research Reading Path 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 starting with jargon before the reader knows what problem the protocol solves. 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 Reading Path
Use this page with a concrete mental test: a reader should be able to explain why their identity can move before they learn every NIP number. 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 Reading Path
The source list is part of the content, not decoration. For Research Reading Path, 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.