How to Use the Nostr Apps Route Map
The Apps route map turns a large archive into a usable reader path. It separates product profiles, categories, developer tools, protocol connections and source evidence so the reader can move through hundreds of pages without getting lost.
The problem with a flat archive
A flat list of hundreds of Nostr app URLs is not a hub. It is a burden. The reader has to guess whether a link is a product, a repo, a category, a guide, a NIP connection, a source snapshot or a historical clue. That might be acceptable for an internal crawl, but it is not acceptable for a public Nostr wiki.
The route map solves this by naming layers. Product profiles explain specific apps. Category guides explain classes of apps. Developer pages serve builders. Protocol connection pages explain standards where they affect products. Source pages preserve evidence. A reader should be able to tell which kind of page they are opening before they click.
That structure protects information without making the first screen chaotic. Nothing useful has to vanish, but not every source needs to compete with the most important user routes.
Product profiles
Product profiles are the main reader pages for specific apps. They should explain the product's role, user type, origin, public surface, Nostr connection, standards, sources, limits and current status. A profile can be about a social client, signer, wallet, media tool, marketplace, publishing app, relay tool or developer-facing product if it has a clear product identity.
A strong product profile does not read like a generic template. Damus is not Primal. Alby is not nos2x. Coracle is not noStrudel. A wallet is not a relay tool. Each page needs its own axis: what problem the product solves, why it matters, what tradeoffs it carries and what a reader should check before using it.
The hub cards point to these profiles when the reader is likely choosing a tool. That is why the favicon shelves link directly to app pages instead of burying products inside a long archive shelf.
Category guides
Category guides explain product classes: clients, signers, wallets, onboarding apps, media apps, group chat, discovery tools, marketplaces, developer tools and more. They do not replace profiles. They give the reader a mental model for comparing many products at once.
A signer category page, for example, explains the trust boundary behind NIP-07, mobile signers and remote signing. A client category page explains why the app is a window into relays rather than the network itself. A wallet category page explains custody, NWC and payment flow. These pages make individual profiles easier to read because the shared context is already clear.
Category guides are also where the hub can name open questions. Which product patterns are mature? Which are experimental? Which standards are widely supported? Which user risks remain unresolved? That context helps readers choose without pretending the ecosystem is finished.
Developer and protocol pages
Developer pages belong to SDKs, libraries, relay tools, command-line utilities, test clients, examples and implementation resources. They are important, but they answer a different question from user-facing app profiles. A builder wants source code, maintenance signals, examples, supported NIPs and integration risks. A normal app user wants to know what to install or trust.
Protocol connection pages explain NIPs only when they affect app behavior. NIP-07 matters for signers. NIP-46 matters for remote signing. NIP-19 matters for identifiers that users copy. NIP-65 matters for relay discovery. These pages should link to the NIPs route for full standards detail rather than duplicating every protocol explanation inside Apps.
Keeping developer and protocol pages distinct gives the hub a cleaner shape. The user route stays readable. The builder route stays deep. The two meet when a product decision depends on a technical standard.
Source pages
Source pages are evidence. They can include repository snapshots, project pages, docs, directory references, package pages and other URLs that support the map. They should not be presented as if they were full product profiles unless they actually explain a product to a reader.
This is where many large routes go wrong. They collect source pages, then expose them all as equal navigation items. The result is a hub where a beginner cannot tell a polished client from a stale repo. The Crays route keeps source pages reachable, but it uses them as support for articles and research paths.
For serious readers, source pages are valuable. They allow verification. For casual readers, they should not be the first screen. The route map balances both needs.
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.how clients - Client overview with platform and product context.
- NIP-07 - Browser signer interface exposed as window.nostr.
- NIP-46 - Remote signing flow for clients and bunker-style signers.
- NIP-65 - Relay list metadata for read and write relay discovery.
