Nostr Apps Directory
The Apps directory is the product shelf of the Nostr atlas. It helps a reader start with the job they want done, then move toward the right client, wallet, signer, marketplace, publishing tool or developer stack without pretending every project plays the same role.
Why a directory matters in Nostr
Nostr does not have one official app store. That is a strength, but it also creates friction for a new reader. A person who comes from a normal platform looks for one canonical product: one Twitter, one Instagram, one wallet app, one help center. Nostr gives them a protocol, many clients, many relays, many signing models and a growing pile of tools that can look similar from the outside while doing very different things.
A good directory solves that confusion without flattening the ecosystem into a popularity chart. Damus, Amethyst, Primal, Coracle, noStrudel, YakiHonne, Iris, Snort, Habla, Highlighter, Zap.stream, Blossom tools, wallet connectors, NIP-07 extensions and SDKs all touch Nostr, but they do not answer the same user question. Some are daily social clients. Some are signing boundaries. Some are publishing surfaces. Some are infrastructure for other builders. Some are experiments that matter because they prove a pattern even if they are not the best place for a beginner to start.
The directory therefore works like a map of product roles. It keeps recognizable product names visible, but it sorts them by what the reader is trying to accomplish. If someone wants to post and follow people, they need client choices. If they want to protect a key in the browser, they need signers. If they want zaps and Lightning flows, they need wallet surfaces and Nostr Wallet Connect context. If they want to ship software, they need libraries, SDKs, protocol references and examples. The point is not to list everything loudly. The point is to remove the first wrong turn.
The app is not the network
The most important sentence on any Nostr apps page is simple: the app is not the network. A Nostr client is a window into signed events and relays. It can feel like the whole experience because it draws the timeline, decides which relays to query, renders profiles, hides spam, shows zaps and decides which NIPs it understands. But the client does not own the identity. The public key stays portable, and the signed event model lets more than one product understand the same object when they share the relevant standards.
That separation is why a directory needs to teach product categories as much as product names. A reader who installs a client and later switches to another client is not starting over in the same way they would when leaving a normal social network. They are carrying a public key, existing events, followed accounts, relay choices and sometimes wallet or signer preferences. The experience can still be messy. Different clients discover different relays, support different NIPs, index different event kinds and make different moderation decisions. But the basic idea is different from a platform account: product choice moves closer to interface preference and trust boundary, not total social identity.
This also explains why the directory keeps source pages and developer notes near the product shelf. A product profile is useful, but Nostr readers often need to know what stands behind the visible interface. Is there a GitHub repository? Is there an app store listing? Does the project publish a website? Which NIPs are part of the app story? Does it use NIP-07, NIP-46, NIP-19, NIP-65, NIP-89, Blossom, NWC or Lightning? Those details are not trivia. They decide whether a tool can move with the rest of the ecosystem.
How the shelves are organized
The Apps hub keeps fast visual shelves because recognition matters. Favicons help a reader spot Alby, Primal, Damus, Amethyst, Coracle, noStrudel, Blossom, Zap.stream or developer projects without reading a paragraph first. That is not decoration. It is a usability layer for a crowded ecosystem where many names are similar, some projects are small and the same tool can appear in more than one conversation.
The deeper route separates app profiles, category guides, developer material and source references. A product profile explains the public surface of a tool. A category guide explains a class of products, such as clients, signers, wallets, media apps, onboarding tools or marketplaces. A developer page belongs to libraries, SDKs, command-line utilities and protocol glue. A source page is evidence: repository, documentation, directory entry, app-store clue or project page. Keeping those types apart makes the hub less chaotic for readers and easier to maintain over time.
Directories such as Nostr Apps and Nostr Compass show why this structure is needed. They track a large, changing ecosystem, and each does useful work by grouping projects into categories. Crays adds a different layer: a reader route. Instead of asking a newcomer to understand every category upfront, the hub starts with the human job: read, post, sign, pay, publish, discover, moderate, build, host or verify.
What belongs here
An app belongs in this route when it gives a user, operator or builder a concrete surface for doing something with Nostr. That can be a social client, a long-form editor, a video or streaming product, a group chat tool, a wallet connector, a signer, a relay admin interface, a marketplace, a search tool, a media host, a curation surface, a library, an SDK or a developer utility. The key test is whether the project helps someone use, build, read, publish, pay through or manage Nostr in practice.
Not every Nostr-adjacent URL deserves to become a full app profile. A blog post about a product may be useful as a source, not a product page. A generic GitHub organization may belong in the developer or source layer. A NIP belongs in the standards route unless it is needed to explain how a product category works. A relay belongs in the relay route unless the tool is mainly an app for relay management. A wallet belongs in the wallet route unless the page is about how that wallet appears as an app surface inside the wider product ecosystem.
That boundary prevents the route from becoming a junk drawer. Nothing useful has to be lost. It can still be linked as evidence, but it does not need to sit beside user-facing apps as if it were the same kind of object. For readers, this distinction is the difference between a map and a pile.
How to read a product profile
A strong Nostr app profile answers several practical questions. What does the tool let the reader do? Which kind of user is it for? Is it a client, signer, wallet, marketplace, media product, developer library or infrastructure tool? Does it use a public key directly, ask for a signer, connect to Nostr Wallet Connect, depend on a relay set, publish source code or support important standards? What are the risks or limits? What should a reader compare it with before committing?
The profile also needs to avoid product worship. Nostr projects are often young. Interfaces change. Repositories go quiet. Some apps are brilliant experiments but not beginner-safe. Some products are polished but hide important tradeoffs. Some are open source, some are not. Some have serious teams behind them, some are weekend projects that nevertheless influence how the ecosystem thinks. A useful profile keeps that texture visible without turning into a takedown or a press release.
For builders, a product profile is also a pointer to patterns. A client profile can reveal how relay discovery works in practice. A signer profile can show where private-key risk enters the user journey. A wallet profile can show how NWC changes payment flows. A marketplace page can show what is still missing around reputation, moderation and dispute handling. The app is the object, but the product lesson is often larger than the app.
Where to go next
If you are new, open Clients after this directory. Clients show why Nostr feels less like one website and more like a set of windows into signed data. Then open Signers before you paste a private key anywhere. That order gives you a safer mental model: first the interface, then the identity boundary, then the wallet and publishing layers.
If you are comparing products, use the favicon shelves first, then open the profile pages. Recognition is fast, but it is not enough. A familiar icon does not tell you which NIPs are supported, whether the project is maintained, how the key is handled or whether a feature depends on a centralized backend. Use the profile to slow down at the right moment.
If you are building, skip directly to Developer Tools and the Research Atlas. The product map is useful for market context, but the source trail is where implementation reality shows up: NIP docs, SDK repositories, examples, open issues, relay behavior and the parts of the ecosystem that are still rough.
Sources worth opening
- nostr.org - Protocol overview and official entry point.
- 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.how clients - Client overview with platform and product context.
- nostr-protocol/nips - Canonical standards repository for Nostr implementation proposals.
- NIP-01 - Base event and client-relay model.
- NIP-65 - Relay list metadata for read and write relay discovery.
