Client

Basics13 min readApps and product surfaces

Client

A client turns signed events into a product experience. That makes it powerful, but it should never be confused with the whole network.

The window, not the network

A Nostr client is the app, website or tool that a person actually uses. It might look like a social feed, a long-form editor, a photo app, a live chat, a relay dashboard, a wallet interface or a developer console. The important boundary is that the client is not the account and not the whole network. It is one window onto signed events carried by relays.

That boundary is the first thing a reader needs to feel. On a platform, the app and the account often arrive as one object. On Nostr, a public key can be used through more than one client. A profile can look polished in one product and incomplete in another. A reply can appear quickly in one interface and be missing in another because relay choice, filters or indexing differ.

The result is both liberating and confusing. It is liberating because a user is not supposed to be trapped in one official app. It is confusing because product quality varies, and a bad first client can make the entire protocol seem worse than it is.

What clients decide

A client decides how to render event kinds, which relays to use by default, how search works, how mentions are resolved, how media is uploaded, how spam is hidden, how replies are threaded, how profiles are discovered and how much protocol complexity is exposed. These choices are not cosmetic. They shape whether Nostr feels like a normal product or a pile of protocol parts.

Clients also decide what kind of Nostr they are building toward. A microblogging client may care most about timelines, replies and mute lists. A long-form client cares about addressable articles, edits and presentation. A wallet-adjacent client cares about zaps, invoices and Nostr Wallet Connect. A developer tool cares about raw event inspection. A relay tool cares about policy, filters and uptime.

This is why the Apps hub matters. It is not a gallery of interchangeable front ends. It is a map of product interpretations built on the same base primitives.

Signing and custody

The most sensitive client decision is signing. Some clients ask the user for a private key directly. Some rely on a browser signer via NIP-07. Some use remote signing flows such as NIP-46. Some mobile clients keep keys locally. Some products are read-only until the user connects a signing method.

For a beginner, this is not a minor implementation detail. If every app receives the private key, every app becomes a risk. If a signer can approve events without exposing the key, the user can try more clients with less danger. A good client explains that difference in the moment it matters, not buried in a help article after the user has already pasted a secret.

The best product habit is to separate identity, permission and interface. The client may be beautiful, but the signing flow decides whether it respects the user's long-term identity.

Relays and discovery

A client reaches the network through relays. It can publish to some relays, read from others, discover relay lists through NIP-65, use relay hints from NIP-19 entities, query search services, or maintain its own indexing layer. Those choices decide whether a timeline feels alive or empty.

This is why two clients can show different results for the same public key. One may query the right relay set, while another may miss old posts, replies or profile data. A client that hides relay complexity too aggressively can feel simple but brittle. A client that exposes every relay detail can overwhelm new readers. The art is in the middle: safe defaults, visible diagnostics and enough control when something goes missing.

A serious Nostr client therefore behaves partly like a social product and partly like a network instrument. It needs taste, but it also needs good plumbing.

NIPs and compatibility

NIPs are how clients learn to speak the same language. NIP-01 defines the base event and client-relay messages. NIP-05 names, NIP-07 signers, NIP-19 shareable entities, NIP-44 encrypted payloads, NIP-57 zaps and NIP-65 relay lists all become real to a user only when clients implement them well.

No client implements every NIP, and no good product should pretend that it does. The better question is whether the client implements the standards that match its job. A wallet client needs a different NIP surface from a photo client. A relay admin tool needs different controls from a writer's editor. Compatibility is not about collecting badges; it is about making the right shared behavior work reliably.

This is where Nostr's small base becomes visible. The protocol is tiny enough for many experiments, but shared standards keep those experiments from becoming isolated islands.

Good questions before choosing a client

A reader choosing a client should ask practical questions. Where does signing happen? Does the app require an nsec or support a signer? Which relays does it use? Can the user edit relay settings? Does it explain missing data? Does it support the NIPs needed for the workflow? Does it show source or project information? Does it make private messages and wallet permissions understandable?

There is no one official answer because there is no one official Nostr app. That is a feature of the model, but it also means the user has to learn how to judge surfaces. Some clients are polished products for everyday readers. Some are experimental demos. Some are developer tools. Some are effectively abandoned. A client should be read as a product with maintenance, defaults and tradeoffs, not as proof that the whole protocol is good or bad.

Limits and honest friction

Clients cannot remove every hard part. They cannot guarantee that all relays store all events. They cannot fix a leaked private key. They cannot make every other client render the same event the same way. They cannot turn every NIP into a finished product experience. They can, however, make those limits visible and less punishing.

The best Nostr clients are honest translators. They hide protocol detail when the user is doing ordinary work, and reveal it when the detail changes risk or outcome. They understand that a beginner does not need a lecture on every event kind, but does need to know why the app wants signing permission, why relay choice matters and why switching clients is allowed.

That is the reader-level definition: a client is a replaceable product surface over signed Nostr data. It is where Nostr becomes usable, but it should not be mistaken for Nostr itself.

There is another client limit that deserves to be named: a client can make Nostr feel more centralized than it is. If one app supplies the default relays, the default ranking, the default media host, the default search and the default wallet flow, many users will experience that app as the network. That may be convenient, but it recreates some of the platform gravity Nostr is trying to loosen.

The counterweight is not to make every user configure everything by hand. That would turn openness into homework. The counterweight is visible portability. A good client lets the user understand which pieces are app-specific and which pieces can be carried elsewhere. It should be clear when a post is a normal signed event, when a feature depends on that product's backend, when media is hosted by a particular service and when a wallet permission is tied to a specific connection.

For product builders, this is a design challenge. The client has to make ordinary actions feel normal while preserving enough protocol truth. A button that says "post" can be fine. A signing prompt that shows the event kind, action and app name can be better. A relay settings screen does not need to dominate onboarding, but it should exist when a reader is trying to diagnose an empty feed. A wallet connection should feel smooth, but budgets and permissions should be visible.

For readers, the client test is practical. Try the same public key in two clients. Does the profile appear? Do follows appear? Do recent notes appear? Do long-form posts appear? Does a zap receipt show? Does a private message history behave as expected? Differences do not automatically mean one app is bad, but they reveal which standards and relay assumptions are actually working.

Specialized clients are especially important. Nostr is not only a public timeline. A music app, marketplace, conference app, photo client, relay dashboard, signer, wallet or developer console may all be Nostr clients in the broad sense because they read, write or interpret signed events. The word client therefore should not be reduced to Twitter-like feed app. It means software that participates in the protocol from the user's side.

This is why the same key can have different lives. In one client it is a public profile. In another it is a publishing identity. In another it is a wallet-adjacent payer. In another it is a developer test account. The client decides which parts of the signed event world become visible and useful. That power is why client quality is ecosystem quality.

The strongest clients will probably become boring in the best way. They will make signing safer without turning every action into a security seminar. They will make relay problems diagnosable without asking every user to become an operator. They will support standards without advertising a wall of acronyms. They will let people switch without making them feel punished for leaving.

Until then, read clients with a gentle suspicion. Ask what they store locally, what they send to relays, what they index on their own servers, what they ask the signer to approve and what happens when you open the same identity somewhere else. That is not cynicism. It is how a portable social protocol becomes a real user habit.

Client design also decides how much of Nostr's culture a newcomer sees. Some clients make the network feel like a Bitcoin-heavy public square. Some make it feel like a calm writing tool. Some make it feel like an image gallery, a developer console, a chat app or a marketplace. That difference is not only branding. It comes from default follows, recommended relays, supported event kinds, moderation defaults, search providers and which actions the interface makes easy.

A good client therefore has editorial power even when it is built on an open protocol. It can elevate certain communities, hide spam, recommend people, choose a ranking model and decide which features deserve first-screen attention. The open protocol makes escape easier, but it does not remove product power. Readers should notice that power instead of pretending every client is a neutral window.

Mobile clients carry a special burden. They need notifications, camera access, media compression, local caches, signer integration, app-store constraints and wallet handoffs. A mobile app that handles Nostr well is doing more than rendering JSON. It is negotiating phone permissions, battery life, background connections, push infrastructure, upload hosts, secure storage and human patience.

Web clients have different tradeoffs. They can be opened instantly and shared easily, but they should be especially careful with private-key prompts. Browser signers help, but not every user has one installed. Progressive web apps, extension signers, remote signers and read-only public-key sessions all create different onboarding paths. The browser is convenient, but convenience can train bad habits if the client asks for too much too early.

Desktop and power-user clients often reveal the network more directly. They may expose relay lists, raw event inspection, filters, logs, local databases and advanced moderation tools. That can be intimidating, but it is valuable for operators, developers and serious users. The ecosystem needs both kinds of clients: gentle first doors and sharp instruments.

For creators, client choice can decide whether Nostr feels worth using. A writer needs drafts, long-form rendering, previews and links that survive outside one app. A musician needs media, payments and audience interaction. A podcaster needs discovery, clips, comments and zaps. A community host needs moderation and group context. A client that is good for short notes may be weak for all of those jobs.

This is why a Nostr wiki should not flatten clients into a single list. The relevant question is not just "does this app support Nostr?" It is "which part of Nostr does this app make humane?" A signer makes key handling humane. A relay dashboard makes infrastructure humane. A media app makes visual publishing humane. A wallet client makes payment permission humane. Different clients civilize different parts of the protocol.

The final client lesson is generous but firm: do not blame the whole protocol for one bad app, and do not trust the whole protocol because one app feels polished. The client is where Nostr becomes lived experience. It deserves careful praise, careful criticism and clear explanation.

Local state is another underappreciated part of client quality. A Nostr event may be portable, but a client still stores preferences, drafts, caches, muted words, relay choices, seen posts, media thumbnails, wallet connection details or database indexes. Some of that state should remain local. Some should be publishable. Some should be exportable. The product has to decide, and the reader should know which parts can survive a move.

Algorithms are also client choices. A chronological feed, a follows-only feed, a trending feed, a web-of-trust feed, a relay-specific feed and a topic feed can all be built on Nostr data. The protocol does not force one ranking. That gives users and builders freedom, but it also means every client carries a worldview. The ranking model should be inspectable enough that users know why they are seeing what they are seeing.

Moderation works the same way. A client can mute, block, filter, label, hide, warn, rank down, use community lists or rely on relay policy. Those choices can make Nostr usable without turning one company into the network's police. They can also hide too much or too little. Good clients give users control and explanation rather than pretending moderation is solved by the protocol alone.

Media clients have a special responsibility around storage. A client may upload images or videos to a storage host and publish events that reference the files. If that host disappears, the signed event can outlive the media. If the host logs aggressively, privacy changes. If the app strips metadata, the user gains safety. If it preserves metadata, the user may leak context. A client that handles media well explains these boundaries in product language.

Wallet-connected clients need even sharper boundaries. A zap button is delightful when it is small and clear. It becomes dangerous when the user cannot see spending limits, wallet permissions or which service will pay. Nostr Wallet Connect, zaps and Cashu-related flows can make social payments feel native, but the client must make budget and custody visible.

Developer clients and inspector tools are the other end of the spectrum. They may show raw JSON, event ids, tags, relays, signatures, filters and subscription messages. Those tools are not built for every reader, but they are essential for keeping the ecosystem honest. When a polished client behaves strangely, an inspector can show whether the event exists, where it was found and which fields another app might be missing.

A strong client profile reads like a product analysis, not a brochure. What can the user do? How does signing work? Which relays are default? Which NIPs matter? What local or server-side state exists? What is portable? What is not? What happens when the user leaves? These are the questions that turn a client list into useful guidance.

Once that habit is learned, the client layer becomes exciting rather than confusing. It is the place where Nostr can become many different products without giving up the shared identity and event model underneath.

The reader does not need to become a developer to ask those questions. They only need to remember that every client is making choices on their behalf, and that the best clients make those choices visible at the moments where trust, money, privacy or portability changes.

Sources worth opening