Nostr Resources and Links
A research map for Nostr: canonical standards first, then clients, relays, developer tools, directories, long-form research and Crays-relevant product references.
A link database is only useful when it has a reading method. Start with primary sources, compare directories with real project pages, and treat every client, relay and NIP as part of a larger map instead of a trophy list.
Start with canonical sources
When you need protocol truth, begin with the NIPs repository and NIP-01. The repository is not a product roadmap. It is a standards shelf. Some NIPs are mandatory, many are optional, and a few are explicitly marked unrecommended when the ecosystem has moved on.
Use Nostr.how when you need plain-language orientation and the Developer Guide when you need the first builder path. Those sources solve different problems: one helps you explain Nostr to a human, the other helps you build without guessing.
Read directories as maps, not verdicts
Nostr Apps, Awesome Nostr, Nostr Compass and other directories are discovery tools. They help you find clients, relays, libraries, file servers, marketplaces, media apps and experiments. They do not prove that a project is maintained, secure or product-ready.
The right habit is triangulation. Open the directory entry, then check the project site, repository, release history, supported NIPs, signer behavior, relay assumptions and whether the product explains risk in normal language.
Separate clients from infrastructure
Clients are the visible layer. They decide onboarding, feeds, profiles, long-form editing, notifications, search, media display, moderation controls and wallet prompts. Infrastructure is less visible but equally important: relays, file storage, indexers, signers, wallets and libraries.
A beginner may only care whether the app feels good. A builder needs to know whether the app signs safely, reads from the right relays, handles missing events, supports NIP-65, respects NIP-05 and avoids turning private keys into paste-and-pray onboarding.
Use the Excel database as a working stack
The research workbook gives us a structured source base: 403 link rows plus dedicated sheets for NIPs, clients, developer stack, relays, long-form research and core directories. That shape is useful because the ecosystem is too broad for one flat bookmark folder.
For Start pages, the most useful rows are not necessarily the newest projects. They are the sources that explain the base model: NIP-01, NIP-05, NIP-07, NIP-19, relay directories, Nostr.how, the Developer Guide, nostr-tools, NDK, strfry, Khatru, Blossom and empirical relay research.
- Core. Protocol home, NIPs, Nostr.how and entry explanations.
- Apps. Client and interface choices.
- Dev stack. Libraries, tools, test utilities and relay frameworks.
- Relays. Live infrastructure, monitoring, paid relays and relay software.
- Research. Long-form analysis that explains trade-offs, not just features.
Track media and storage separately
Nostr events are small signed records. Images, video, large files and other blobs need adjacent storage. NIP-96 describes HTTP file storage but is now marked unrecommended in favor of Blossom in the NIPs repository. Blossom addresses blobs by sha256 hash and uses Nostr keys for identity and authorization.
That matters for creators and venues. A post can be portable while the media behind it is fragile. Good resource pages should therefore track file metadata, storage servers, Blossom, NIP-94, upload authorization, mirroring and deletion behavior.
What belongs in a serious resource page
A serious Nostr resource page should tell you what a source is good for, what it does not prove and where it sits in the stack. A GitHub repo may be primary for implementation, but weak for onboarding. A blog post may be excellent for framing, but not authoritative for NIP details.
That is the standard for this archive: fewer random outbound links, more annotated context. If a link does not help you decide what to learn, build, test or distrust next, it does not deserve a prominent place.
The workbook categories behind this page
The Excel database separates the ecosystem into useful research shelves: core sources, standards and NIPs, clients and apps, developer stack, relays and infrastructure, reads and research, and core directories. That matters because Nostr research fails quickly when everything becomes one flat list.
For example, a NIP tells you a possible data format. A client listing tells you who might implement it. A relay monitor tells you whether infrastructure is alive. A repository tells you whether code exists. A long-form essay tells you why people care. Those are different evidence classes.
What to verify before citing a project
Before we treat a client, relay or tool as important, we should check more than its name. Look for an official URL, a repository or release page, supported platforms, supported NIPs, signer behavior, relay assumptions, wallet permissions, media storage approach, last visible activity and whether other clients can read the data it creates.
That is the difference between a link directory and a knowledge hub. A directory says where to go. A knowledge hub says what the link means and how much trust it deserves.
Source shelves worth bookmarking
These are the shelves that should stay close while expanding the archive. The NIPs repository is the protocol shelf. Nostr Apps and Awesome Nostr are discovery shelves. Nostr Watch and relay directories are infrastructure shelves. Developer libraries such as nostr-tools, NDK, rust-nostr and go-nostr are implementation shelves. Long-form research gives judgment and context.
How to turn links into page depth
Every strong page should convert sources into explanation. If a page mentions NIP-47, it should explain the wallet permission model. If it mentions Blossom, it should explain sha256 blobs and authorization. If it mentions a relay directory, it should explain what relay quality means. If it mentions a client, it should explain what the client changes for you.
That is the rule I am applying to the Start route now: links are not decoration. They are raw material for facts, trade-offs and examples.
How to place Nostr Resources and Links on the map
Read Nostr Resources and Links 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 Nostr Resources and Links 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 Nostr Resources and Links should help you decide
A good page about Nostr Resources and Links 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 Nostr Resources and Links
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 Nostr Resources and Links
The source list is part of the content, not decoration. For Nostr Resources and Links, 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.