Nostr Apps Research Atlas
The Research Atlas is the slower layer behind the product shelf. It helps a reader check where a Nostr app comes from, what it claims to support, how it is maintained and which sources are strong enough to trust.
Why source trails matter
Nostr is open, fast-moving and uneven. A project can be a polished app, a prototype, a repo with no public website, a directory listing, an app-store build, a relay experiment or a library that powers other apps without being user-facing. A reader needs a way to tell the difference. The Research Atlas exists to keep those clues visible.
A product profile without sources can become marketing. A source list without interpretation can become noise. The useful middle is an article that names the app's role and links to the evidence that lets a reader verify it: official website, GitHub repository, documentation, app-store listing, NIP reference, release notes, maintainer profile, directory entry, public demo or credible discussion.
This matters especially for key-handling tools, wallets and clients. If a product asks for signing authority, wallet access or social trust, the reader should be able to inspect more than a logo and a slogan. Source quality becomes part of product quality.
What counts as strong evidence
The strongest source is usually the project's own maintained home: official website, repository, documentation or app-store listing. A GitHub repo can show code, issues, commit history, license and maintainers. A website can show user-facing claims, onboarding paths and current positioning. An app-store page can show platform availability, screenshots and update cadence. None of these is perfect alone, but together they form a trail.
Directories such as Nostr Apps and Nostr Compass are useful secondary sources because they help discover projects and categories. They are not a substitute for checking the project itself. A directory can list a tool that later changes, becomes stale or shifts category. Crays uses directories as entry points, then walks toward the primary source when possible.
Protocol sources matter when a product claim depends on a standard. If a web app says it works with browser signers, NIP-07 is relevant. If a product uses remote signing, NIP-46 belongs in the source block. If an identifier is part of the experience, NIP-19 or NIP-05 may matter. Standards are useful only when they explain a concrete product behavior.
Weak clues and how to use them
Not every useful clue is strong enough to carry a profile. A social post can announce a feature but may age badly. A screenshot can show an interface but not maintenance. A package page can prove a library exists but not that it is actively used. A broken website may still point to an important historical project. These clues can be included, but they need to be labeled by context.
The Research Atlas keeps weak clues from disappearing while avoiding the mistake of treating them as product truth. For example, a repository with no recent commits may still be important historically. A client with no public repo may still be widely used. A directory listing can reveal a project name, but the profile needs more before it makes strong claims.
This is reader-first research. The question is not whether a URL exists. The question is whether this source helps a reader understand what the app is, how current it is and what risks or limits belong to it.
How to research a Nostr app
A good research path starts with the name, official website and repository. Then check directory listings, app stores, docs, NIP references, issue history and public maintainer activity. Search for the exact project name with Nostr, GitHub and relevant protocol terms. If the project is a signer, look for NIP-07, NIP-46 and key-storage details. If it is a wallet, look for NWC, Lightning, custody model and permissions. If it is a client, look for supported platforms, relay behavior and account import or signer flow.
After gathering sources, sort them by role. Primary sources explain the project. Protocol sources explain the standard. Directory sources help place the project in the ecosystem. Commentary can add context but should not replace the project's own materials. Dead or stale sources can still be noted when they explain history, but they should not be used to make current claims.
The resulting profile reads like a guide, not a spreadsheet. The reader needs a story: what the app is for, why it matters, how it fits Nostr, what to check before using it and where the proof lives.
What the Atlas protects against
The Atlas protects against three common mistakes. The first is hype: a project gets treated as important because it has a nice name or screenshot. The second is neglect: an important tool disappears from the map because it has no polished website. The third is confusion: source URLs, profile pages, category guides and protocol documents all collapse into one list.
A good research page keeps the ecosystem honest without making it sterile. It can say that a project is promising but early, useful but narrow, polished but closed, powerful but risky, historical but no longer active, or small but technically important. That is the kind of nuance a serious Nostr wiki needs.
The result is not a perfect database. It is a reader-facing research habit: check the product, check the source, check the protocol claim and then decide how much trust the page deserves.
Sources worth opening
- Nostr Apps - Directory of Nostr products grouped by use case and platform.
- Nostr Compass projects - Project directory with clients, wallets, signers, relays and developer tools.
- nostr-protocol/nips - Canonical standards repository for Nostr implementation proposals.
- nostr-tools - Widely used JavaScript library for Nostr events and relays.
- Nostr Dev Kit - TypeScript toolkit for higher-level Nostr app development.
- rust-nostr - Rust ecosystem for Nostr libraries, SDKs and services.
- NIP-07 - Browser signer interface exposed as window.nostr.
- NIP-46 - Remote signing flow for clients and bunker-style signers.
