Search Atlas
One search door into the Crays Nostr hub: pages, people, apps, NIPs, source trails, Excel URLs, media archive entries and research branches.
The Search Atlas is the working memory of the Nostr hub. It lets a reader search by idea, NIP number, person, project, URL, domain, app name, source title or our route without guessing where the archive stored the page.
What the atlas searches
The live search reads the generated Nostr index, not a decorative page list. It covers article titles, slugs, decks, categories, shelves, key terms, source cards, research text and the exact workbook URLs preserved from the deep Nostr source audit.
That means a copied Excel URL, a domain like nostrapps.com, a NIP number, a project name or a person can all become an entry point into the same library. The search box above is the fastest route; this page exists so the route itself never disappears.
- Pages. Every generated Nostr article and route page in the hub.
- Research. Deep-research source pages, workbook URL variants and source inventory entries.
- People and apps. Profiles, app catalog entries, project research and builder context.
- NIPs and relays. Protocol pages, NIP references, relay market pages and implementation routes.
How to use it
Start broad when you need orientation, then narrow with the exact term. Search for 'NIP-72', 'Primal', 'Lyn Alden', 'Blossom', 'nostrlogin.org', 'relay auth' or a full source URL. The strongest matches appear first, and each result keeps its category and shelf visible so you can see where it belongs.
If a term has no result, that is useful too. It tells us where the hub needs a new page, a deeper source trail or a better internal synonym.
- Exact URL. Paste a workbook or web URL when you want the audit trail.
- NIP number. Use NIP-07, NIP-46, NIP-50, NIP-72, NIP-98 or any tracked standard.
- Project name. Search apps, relay tools, signers, media projects and wallets.
- Person. Use the People route when the public contribution context is clear.
Why this matters
A large archive becomes useful only when readers can move through it without memorizing the structure. The Search Atlas is the pressure valve: it keeps the 12 main routes intact while still letting a reader jump directly to the thing they came for.
For us, this also protects the research workflow. New crawler findings, project submissions and source-review entries can be added to the index before they become polished editorial pages, so the archive keeps its memory without publishing unreviewed material as finished Crays content.
Apps CatalogUse the app route for product and client discovery.
PeopleUse the people route for builders, funders, media voices and public contributors.
How to use this source
Search Atlas belongs to the research and source material layer. The page should help you answer one concrete question instead of forcing you through a generic Nostr essay.
The short version is: One search door into the Crays Nostr hub: pages, people, apps, NIPs, source trails, Excel URLs, media archive entries and research branches. The deeper version is to see which concept, standard, product surface or human decision actually changes because of it.
Evidence quality
The useful machinery around Search Atlas is keys, clients, relays, signed events, NIPs, wallets, media and search layers. Name those moving parts directly, because vague protocol language is where confusion starts.
In the search-atlas chapter, A strong page gives you enough context to recognize the term in another client, NIP, relay policy, wallet prompt or source document without pretending every reader is already a protocol engineer.
- Source type. Standard, repo, monitor, directory, essay or research paper?
- Claim. What claim does this source support?
- Next use. Which article should absorb the insight?
What it can verify
Test Search Atlas by asking what is signed, where it is stored, who renders it, which relays or services are involved and what survives when the first app or server is unavailable.
In the search-atlas chapter, That test keeps the explanation tied to reality. It also tells us which internal links belong in the body: foundations first, then standards, then practical examples.
What it does not prove
In the search-atlas chapter, The main risk is that the page can become a definition instead of an explanation. The page should say that plainly and then show the safer reading: what works today, what is experimental and what needs source verification.
In the search-atlas chapter, This is where dense content beats long content. Give the reader facts, constraints, examples and next steps instead of repeating broad claims about openness or decentralization.
Where the knowledge should feed
For us, Search Atlas matters only when it improves understanding or helps a real flow: identity, publishing, relay choice, signing, payment, media, moderation, commerce, venue context or governance.
In the search-atlas chapter, That does not mean every page has to become our product pitch. It means the page should make the connection visible when the topic affects our ecosystem, and stay purely educational when it does not.
Library path around it
The best next step from Search Atlas is not a generic link pile. Connect it to the closest prerequisite, the closest technical standard and the closest practical example.
In the search-atlas chapter, A large archive becomes useful when every page behaves like a node in a knowledge graph: this explains one thing, points to what it depends on and shows where the idea is used.
How to place Search Atlas on the map
Read Search Atlas 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 Search Atlas 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 Nostr protocol repository, Nostr NIPs, nostr.how, Nostr Login. Treat those as anchors, then compare product behavior and NIP support.
CatalogRead this beside Search Atlas when you want the neighboring concept.
Complete IndexRead this beside Search Atlas when you want the neighboring concept.
NIP-07This concept is part of the working vocabulary behind Search Atlas.
What Search Atlas should help you decide
A good page about Search Atlas 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 Search Atlas
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 Search Atlas
The source list is part of the content, not decoration. For Search Atlas, 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.
Read next from Search Atlas
Complete Nostr Apps CatalogApps and clients
Complete NIP Archive IndexProtocol and NIPs
Nostr People, Founders and BuildersPeople and culture
NIP-07: Browser SignersProtocol and NIPs
NIP-46: Remote Signing and Nostr ConnectProtocol and NIPs
NIP-98: HTTP AuthProtocol and NIPs