CraysNostr Clients
A Nostr client is the reader's current window into the network, not the network itself. The best way to compare clients is to ask what they reveal, what they hide, which standards they understand and how gently they handle identity, relays, media, zaps and trust.
What a client really does
A Nostr client reads and writes signed events through relays. That sounds technical, but the product consequence is easy to feel: the client is the interface that turns a public key, relay set and event stream into something that looks like a social app, a publishing tool, a video page, a chat surface or a wallet-adjacent feed. It chooses layout, timelines, search, notifications, profile rendering, moderation tools, media previews and the signing path. Those choices determine how Nostr feels, even though the client does not own the underlying identity.
This is why two Nostr clients can make the same public key feel almost like two different accounts. One may emphasize global notes and zaps. Another may emphasize communities or long-form writing. Another may default to different relays, hide spam more aggressively, show only certain event kinds or surface wallet actions more clearly. The protocol makes portability possible; the client decides how much of that portability a normal person can actually understand.
For a reader, the safest mental model is this: the client is a lens. A good lens shows enough of the network to be useful while giving the user control over identity, relays and signing. A weak lens may still work, but it can make Nostr look empty, confusing or riskier than it needs to be.
Why the same Nostr can look different
Nostr is not a single global database with one official feed. Clients ask relays for events. They decide which relays to connect to, how long to wait, which event kinds to display, how to rank or thread replies and how to handle missing data. If a friend posted something to a relay your client is not reading, it may look absent. If another client reads a broader or better relay set, it may appear there. That is not necessarily censorship or failure; it is part of how a relay-based system behaves.
NIP-65 relay list metadata helps clients understand where a user tends to read and write, but support and interpretation vary. Some clients do more to discover outbox relays. Some lean on their own indexing services. Some are optimized for speed and consumer polish. Others are more transparent but rougher. This tradeoff matters because a newcomer rarely blames relay discovery. They blame the app. A strong client hides complexity only after it has made the user safer.
The same is true for NIPs. NIP-19 identifiers make public keys and events easier to copy. NIP-07 helps web apps sign without directly holding a private key. NIP-46 enables remote signing. NIP-57 enables zap flows. NIP-23 supports long-form content. NIP-29 touches groups. A client that supports one cluster of standards can feel like a different product category from a client focused elsewhere.
Consumer clients and specialist clients
Damus helped make Nostr visible on iOS by giving people a recognizably social mobile surface. Amethyst became important on Android because it treated Nostr as a broad client problem, not just a short-note feed. Primal invested in a polished consumer experience and a wallet-connected product layer. Coracle explored web-client ideas around relays, lists, communities and user agency. noStrudel became useful for power users and developers because it exposes protocol details that more polished apps may hide.
Those products are not interchangeable even when they all let someone read and post. A beginner may need the smoothest route. A builder may want visibility into event kinds, relays and raw objects. A writer may care about long-form notes and discovery. A community operator may care about groups, moderation and lists. A zap-heavy user may care about wallet flow. A privacy-sensitive user may care most about where the private key is stored and how remote signing works.
The Apps hub keeps these products together because the reader often enters through a single question: which app should I use? But the answer has to split quickly. Nostr clients are not just skins. They are product theories about what an open social protocol is for.
The key question behind every client
Before choosing a client, ask how it handles the private key. Some clients create or import keys locally. Some rely on browser extensions through NIP-07. Some work with Android signers such as Amber. Some can connect to a NIP-46 remote signer. Some product journeys make it too easy to paste an nsec into a website because that reduces friction. That may be convenient, but it is the wrong default for many readers.
A platform password can often be reset by the company that hosts the account. A Nostr private key signs the identity itself. If a client stores it poorly or asks for it casually, the user may carry that risk across the whole ecosystem. This is why the client page links directly to signer pages. The client is the face of the product, but the signer is often the trust boundary.
A good client explains the difference between public key, private key, signer, wallet and relay without burying the user in protocol words. It lets a new reader begin, but it does not train them to treat a private key as a normal login field.
How to compare clients
Compare clients by the jobs they handle well. Can you onboard without key mistakes? Can you find people? Can you follow lists? Can you choose or inspect relays? Does search work? Are zaps understandable? Does media load reliably? Can long-form content be written or only read? Are communities supported? Does the client publish enough information about its source, team or repository? Does it use open standards or depend on private infrastructure that only its own product understands?
Also compare the emotional texture. Some clients are quiet and precise. Some are loud and feed-first. Some expose too much technical machinery for a first-time user. Some hide too much for anyone who wants to learn. The best client for a new reader may not be the best client for a developer, journalist, event host, wallet user or relay operator.
The Crays app route therefore does not rank clients as a single ladder. It groups them by the kind of doorway they create into Nostr. A polished mobile client, a protocol-heavy web client and a long-form publishing tool can all be excellent while serving different readers.
A safe first route
A sensible first route is: learn the key model, install a client that does not make key custody mysterious, choose a signer when the product supports it, follow a few known accounts, then inspect relays only after the basic flow is clear. That order keeps the first experience from becoming a relay debugging session.
After the first week, switching clients becomes part of learning. Try one polished client, one web client and one power-user client. Notice what changes. If the same identity looks richer in one app and thinner in another, ask which relays, NIPs and indexing choices are different. That comparison teaches more than a definition page can.
Clients are where Nostr either becomes legible or loses people. The protocol can be elegant, but readers meet it through product surfaces. That makes client pages some of the most important pages in the Apps hub.
Sources worth opening
- nostr.how clients - Client overview with platform and product context.
- Damus - iOS client that helped make Nostr visible to mainstream mobile users.
- Primal - Consumer Nostr client and wallet surface.
- Coracle - Web client exploring relays, communities and social graph control.
- noStrudel - Web client and protocol-friendly Nostr interface.
- NIP-01 - Base event and client-relay model.
- NIP-65 - Relay list metadata for read and write relay discovery.
- NIP-07 - Browser signer interface exposed as window.nostr.
- NIP-46 - Remote signing flow for clients and bunker-style signers.
