CraysNostter
Nostter is a web Nostr client that feels simple on the surface but carries a serious amount of protocol work underneath: signers, bunker sessions, relay lists, metadata relays, NWC payments, custom emoji, bookmarks, mute lists, profile state and browser-native app behavior.
A quiet web client with a lot underneath
Nostter looks modest at first glance. The public repository describes it in one short sentence: a Nostr client for web. That simplicity is part of its appeal. It does not announce itself as a grand social network, a wallet, a creator platform or a protocol laboratory. It opens as a web client where a reader can browse, sign in, post, react, follow, search, manage relays and use the familiar Nostr social layer without installing a platform-specific app.
The project is more substantial than that short description suggests. The current repository is active, AGPL-3.0 licensed, written primarily in Svelte, and built with SvelteKit, Vite, Cloudflare deployment tooling, nostr-tools, rx-nostr, rust-nostr bindings, Dexie, emoji handling, QR generation and Lightning invoice decoding. The web app has a PWA manifest, a share target and a protocol handler, so it is intended to behave like a resident browser app rather than a temporary demo page.
That combination makes Nostter useful to two different kinds of readers. A normal user can treat it as a clean web Nostr client. A more technical reader can inspect a living codebase that shows how a modern browser client handles signers, relay lists, Nostr Connect, wallet connect payments, local state and Japanese community defaults. Nostter is not loud, but it is not shallow.
The project is alive
Activity matters when choosing a Nostr client. A stale client can still load public notes, but signing, search, media previews, wallet flows and private-message behavior age quickly as protocol habits change. As of June 12, 2026, the SnowCait/nostter repository showed 176 stars, 33 forks, 65 open issues, a push at 05:39:56 UTC and a same-day merge commit, c43bcef, for showing users without kind 0 metadata in followees, followers and list members. That is a good signal for an app that depends on live web, relay and signer behavior. It also tells you the maintainer is still working on unglamorous social-client details: incomplete profile metadata, list rendering and the real mess of follow graphs.
The release history gives the project a simple arc. The beta appeared in March 2023. Version 1 followed in October 2023, still pointing to the original Vercel deployment. Version 1.1 in November 2023 marked the move to the new domain and logo at nostter.app. The app itself now warns users who land on the older nostter.vercel.app host that the project has moved to nostter.app. That sort of migration detail is boring in the best possible way: it is what maintained software does.
The open issue list is also useful because it shows real pressure points. Recent and older discussions include animated image detection, custom emoji layout problems, NIP-92 imeta work, mobile interface requests and user-status controls. Those are not abstract protocol debates. They are the rough edges a web client meets when people use it every day: media, layout, metadata, client polish and the long tail of event kinds.
Login choices define the trust model
Nostter offers several ways in. The README recommends NIP-07 browser extensions, and the login view supports browser-extension signing through nip07-awaiter. It can also generate a new nsec, accept an existing nsec, accept an npub for read-only use, or connect through a NIP-46 bunker URL. Those choices are not cosmetic. They determine where your private key lives and which software has permission to sign events.
The safest everyday pattern for a serious identity is usually an external signer. With NIP-07, Nostter asks the browser extension to sign, and the extension remains the place where key custody and approvals should be inspected. With NIP-46, Nostter can connect to a remote signer through a bunker session. With a raw nsec, the browser app itself becomes part of the private-key custody story. That may be fine for a test account. It deserves more caution for a long-lived public identity.
Read-only npub mode is a useful low-risk entry point. A reader can look around, inspect profiles, search, open notes and understand the app before authorizing any signing path. That makes Nostter friendlier than clients that force key entry immediately. Start there when evaluating it, then add signing only after checking which browser profile, extension, device and relay settings you are actually using.
NIP-46 works in both directions
Nostter is interesting because it does not only consume remote signing. It can connect to a bunker, and it can also expose itself as a remote signer. The signer source supports NIP-07, bunker URLs and nsec-backed local signing. The remote-signer source can create a bunker URL, store a session secret, listen on a relay and answer signing methods such as connect, ping, get public key, sign event, NIP-04 encryption and NIP-44 encryption.
That is a deeper implementation than a simple sign-in button. A browser client that understands NIP-46 can participate in a wider signer ecosystem where the client, signer and relay are separate pieces. The default remote-signer relay in the source is an ephemeral relay, and the session has its own stored secret. A careful user should learn where those messages go and how the session can be revoked or replaced.
The practical value is flexibility. A person can use Nostter as a normal client with a browser extension. They can connect it to a remote signer when they do not want the web app to hold the long-term key. They can also use Nostter's signer behavior for another client in certain setups. The practical risk is the same flexibility: a bunker session is only as safe as its approval interface, relay choice, session-secret handling and revocation habits.
Relays are chosen with geography in mind
Nostter's relay defaults say a lot about the app. The constants include broad public relays such as nos.lol and relay.damus.io, metadata relays such as purplepag.es and user.kindpag.es, search relays such as nostr.wine and search.nos.today, and trend relays for buzz-style discovery. The same file also adds Japanese local relays when the user's locale starts with Japanese.
That locale behavior matters. Nostr often pretends to be global by default, but social discovery still depends on where people publish, which communities maintain relays and which relays a client chooses early. Nostter's Japanese relay additions make the client less neutral in a useful way. It tries to meet Japanese-language users and the Japanese Nostr scene closer to where their content already lives.
The reader should still inspect relay settings. Defaults are starting points, not guarantees. If a feed looks empty, a search result is thin or a profile appears incomplete, the problem may be relay selection rather than the app. Nostter's default lists show thoughtful curation, but Nostr is not a single database. A reliable experience still depends on matching your follows, region, language and use case with the relays that actually carry those events.
Metadata and relay lists are first-class concerns
Nostter reads more than short notes. The author code fetches and stores profile metadata, contact lists, relay lists, custom emojis, bookmarks, profile badges, preferences, last-read markers, mutes and channels. It uses replaceable and parameterized replaceable events for state that should be updated over time rather than treated as one-off posts. That is exactly where many Nostr clients become complicated: the social feed is only the visible layer.
Relay-list handling is especially important. The relay-list source fetches kind 10002 relay-list metadata and can fall back to relay information embedded in older contact-list events. That keeps Nostter compatible with more than one era of Nostr client behavior. It also means the app can follow where a user says they publish and read, instead of assuming every profile lives on the same small set of relays.
For a reader, the value is continuity. If your profile, relay list, bookmarks or mute list are signed as Nostr events, other clients may be able to understand parts of that state. The limitation is that not every client implements every event kind in the same way. Nostter gives those pieces real attention, but portable state still requires testing across the specific clients you care about.
Zaps use Nostr Wallet Connect
Nostter supports Lightning zaps through Nostr Wallet Connect. The wallet-connect settings screen stores a NWC connection string, validates the nostr+walletconnect form and points users toward wallets such as Coinos and Alby. The zap code builds a NWC pay-invoice request, signs it, sends it to the wallet service relay and waits for a wallet response event tied to the request.
That is a good fit for a web social client. Nostter does not need to become a Lightning wallet to let a user zap. It can ask a connected wallet to pay a Lightning invoice, while the wallet remains the place that holds funds, spending limits and wallet-side approval behavior. This keeps the social app and money custody separated, as long as the NWC connection is created carefully.
Small-payment testing is essential. Connect a wallet with low limits, send a tiny zap, confirm the wallet's payment history and make sure failure states are understandable. A zap can fail because of a wallet permission, relay response, invoice problem, recipient metadata issue, network delay or browser storage state. Nostter implements the NWC flow; it cannot remove the need to test the full payment path.
Browser app behavior is part of the product
The web manifest describes Nostter as a standalone social app with a start page, icons, a share target and a protocol handler for web+nostr links. Those are small details, but they change how the app fits into daily use. A reader can install it like a PWA, share text or links into it, and let the browser hand certain Nostr references to the app.
That matters because Nostr is full of portable identifiers. Users move through npubs, notes, events, addresses and profile links copied from many clients. A web client that can receive those links and accept shared text becomes more than a website. It becomes part of the operating environment around Nostr, especially on devices where installing a native client is inconvenient.
The browser context also sets limits. PWA behavior depends on the browser and operating system. Background behavior, notification reliability, storage persistence and share-target support differ across desktop and mobile environments. Nostter can take advantage of these web platform features, but a user should test them on the actual browser they plan to use.
Custom emojis, media and imeta work show daily-use detail
Nostter's dependency list and issue tracker show attention to the expressive parts of Nostr. The app uses emoji-kitchen-mart, handles custom emoji state and has open discussion around layout when very wide custom emoji reactions appear. That may sound minor until you spend time in Nostr communities where custom emoji, reaction images and visual shorthand are part of the local culture.
The source also includes media-related helpers and imeta components, and an issue tracks NIP-92 imeta support. NIP-92-style media metadata is one of those protocol details that can improve how clients show images and files, but only when enough clients implement it carefully. Nostter's presence in that conversation is a sign that it is not only rendering plain text and hoping media links work.
A reader should still treat media as distributed infrastructure. A Nostr event can point at an image, video or file, but availability depends on the storage service and the metadata quality. Nostter can improve previewing and rendering, and it can adapt to newer event metadata, but it cannot guarantee that every linked file remains online. Test media behavior across another client before relying on it for important publishing.
Preferences, mute lists and bookmarks are signed data where possible
Nostter stores some app state in the browser, but it also uses signed Nostr events for portable user preferences. The preferences source uses kind 30078 with a nostter-specific identifier to save settings such as reaction emoji and media uploader choices. The mute source works with kind 10000 mute lists and can encrypt private mute tags before publishing.
Bookmarks and custom emojis follow the same broader pattern: user state should be expressed in Nostr events when it benefits from portability and identity binding. That does not mean every setting should be public. The mute-list code is careful about private tags, and the user still needs to understand what is public, what is encrypted, what is local and what other clients can read.
This is where Nostr clients become personal software rather than only readers. Your mute list, bookmarks, preferences and relay choices shape the network you experience. Nostter gives these pieces dedicated code, which is better than hiding them as incidental browser state. The reader's job is to check which settings are shared across clients and which are specific to Nostter.
The stack is modern but inspectable
Nostter's package file shows a current web stack: Svelte 5, SvelteKit 2, Vite 7, Cloudflare adapter, Wrangler, Vitest and Playwright. The Nostr layer uses nostr-tools, rx-nostr, rx-nostr-crypto, rust-nostr bindings and nip07-awaiter. Dexie handles IndexedDB-style local data, while QR, Lightning invoice decoding, markdown, media and UI helpers fill out the client surface.
That stack will be familiar to web developers, but the AGPL-3.0 license changes the project posture. Readers and builders can inspect the source, run it, study it and understand how the app handles keys, relays and wallet connections. For a Nostr client, inspectability is not decoration. A client asks to sign social events and sometimes payment requests. Source visibility gives users a way to audit behavior, even if most users will not read every file.
There is still a trust step. A public repository does not automatically prove that the deployed website is identical to the source, and a web app can change between visits. That is why external signers matter. Nostter's inspectable source is valuable, but the safest browser-client posture is to keep important private keys in a signer that asks for approval and can be revoked.
Search, trends and public mode make it useful before login
Nostter can be useful before a user signs anything. Read-only npub login, public browsing and search relays let a reader explore the network without giving the app a private key. That matters for onboarding because Nostr should not require a person to make a permanent identity decision before they understand what a client feels like.
The constants separate several kinds of relays: defaults for ordinary use, metadata relays for profile and identity information, search relays for query behavior and trend relays for discovery. That separation gives the app more chances to find the right data for the screen the reader is using. It also reveals the fragmented nature of Nostr discovery. Search, identity, trends and home feed data do not necessarily come from the same place.
Use that as a learning tool. Search for a profile, open it, compare the relay list, then open the same profile in another client. If the results differ, you are seeing Nostr's relay model, not necessarily a bug. Nostter is a good place to learn that distinction because it exposes enough of the network to make the difference visible without forcing the user into developer tooling.
Japanese Nostr context is a real advantage
The Japanese onboarding guide for Nostter and the Japanese relay defaults make the app especially relevant for readers interested in Japan's Nostr scene. Nostr has always been geographically uneven in practice. Some relays, clients and communities become important because actual people gather around them. Nostter acknowledges that by adding Japanese relay choices when the locale calls for it.
That does not make Nostter a Japan-only client. The app is broadly usable, and its defaults include public international relays. The point is that language and geography are treated as part of the user experience. A Japanese-speaking reader should not have to discover every local relay by accident. A global reader can still benefit from an app that understands regional relay reality instead of pretending every user starts from the same social graph.
For community discovery, this is valuable. A client can make the early network feel alive or empty depending on relay and language defaults. Nostter's choices help the former. As always, readers should adjust settings over time, but the initial posture is more thoughtful than a one-size-fits-all relay list.
What to test before relying on it
Start with a low-risk identity. Open Nostter in read-only mode or with a test key. Then try the signer path you actually want: NIP-07 extension, bunker connection or another supported method. Confirm what the app asks the signer to do, how approvals appear, where session data is stored and how you would revoke access if you changed your mind.
Next test relays and state. Open your profile, follows, notifications, bookmarks, mute list, custom emojis and relay list. Compare a few important threads in another client. If Nostter misses an event, check relay coverage before assuming the event is gone. If it sees something another client misses, inspect which relay carried it. This is the normal discipline of using Nostr seriously.
Finally test money and media with tiny stakes. Add NWC only with a wallet that has spending limits. Send a tiny zap, confirm the wallet history and check whether the recipient event appears as expected. Share a small media link and inspect how another client renders it. Nostter is capable, but browser clients deserve careful testing around keys, payments and storage.
Who Nostter is best for
Nostter is best for readers who want a clean web Nostr client with serious underlying protocol support. It is especially attractive if you prefer browser-first software, want a client that can install as a PWA, use an external signer, pay zaps through NWC, browse before login and keep an eye on relay behavior without turning every screen into a technical dashboard.
It is also useful for builders. The source is compact enough to study and modern enough to reflect current web-client work. Login, bunker signing, relay defaults, NWC payment requests, custom emoji, bookmarks, preferences, mute lists and PWA handlers are all visible in code. A developer can learn a lot from how Nostter connects these pieces.
It is less ideal if you want a native mobile client, a conservative wallet, or a client where every important data path is hidden behind a polished consumer layer. Nostter's strength is different: it is an open, active, web-native Nostr client with thoughtful regional defaults and enough protocol depth to serve both everyday readers and curious builders.
Sources worth opening
The most useful reading path begins with the live Nostter app, the GitHub repository, releases and README, then follows the source files for login, signing, remote signing, relays, NWC zaps, preferences, mute lists, bookmarks, custom emoji, media metadata and the NIPs behind those behaviors.
- Nostter live app
- Nostter about page
- Nostter GitHub repository
- Nostter June 12, 2026 follow-list metadata commit
- Nostter README
- Nostter AGPL-3.0 license
- Nostter v1.1 release
- Nostter v1 release
- Nostter beta release
- Nostter package file
- Nostter web app manifest
- Nostter constants and relay defaults
- Nostter app layout and login restore
- Nostter login screen
- Nostter signer implementation
- Nostter remote signer implementation
- Nostter Wallet Connect settings
- Nostter zap source
- Nostter author state source
- Nostter relay list source
- Nostter preferences source
- Nostter mute list source
- Nostter bookmark source
- Nostter custom emoji source
- Nostter imeta component
- Nostter NIP-92 imeta issue
- Nostter custom emoji layout issue
- Nostter animated image pull request
- Japanese Nostter getting started guide
- Nostter Scrapbox note
- NostrApps listing for Nostter
- Nostr NIPs repository
- NIP-07 browser signer
- NIP-19 bech32 identifiers
- NIP-25 reactions
- NIP-28 public chat
- NIP-44 versioned encryption
- NIP-46 Nostr remote signing
- NIP-47 Nostr Wallet Connect
- NIP-51 lists
- NIP-57 Lightning zaps
- NIP-65 relay list metadata
- NIP-92 media attachments
