CraysSnort
Snort is a fast Nostr social client with a deeper technical story than its timeline suggests: the same project ships the web app, TypeScript protocol packages, a worker-relay cache, signer flows, wallet wiring, media uploads and a long record of security hardening.
A social client with a protocol toolkit underneath
Snort looks simple from the outside: open snort.social, sign in, read notes, reply, repost, zap, search, follow people and adjust relays. That first impression is accurate enough for a normal user. It is also incomplete. Snort is one of the Nostr clients where the public product and the developer stack are closely tied together. The same repository contains the web app, reusable TypeScript packages, wallet code, a browser worker relay and documentation for developers building other Nostr applications.
The repository README describes Snort as a Nostr UI built with React with an emphasis on speed and efficiency. The app package checked for this article is version 0.5.3 and uses React 19, Vite 7 and Bun. GitHub metadata checked on June 12, 2026 showed 340 stars, 132 forks, 6 open issues, an MIT license and a repository pushed on May 29, 2026. The docs describe the Snort libraries as a suite that powers snort.social, zap.stream, dtan.xyz, nwb.tf, lnvps.net and other Nostr projects. That makes Snort more than a timeline. It is a production client that also exports ideas about how Nostr apps can query, cache, sign, encrypt and route events.
The public distribution trail is active rather than frozen. Google Play lists Snort under v0l with 10K+ downloads, 24 reviews, a 3.6 average, an April 8, 2026 update and data-safety declarations that no data is collected or shared. Umbrel lists Snort v0.5.3 as Fast Nostr UI for umbrelOS, while the GitHub release for v0.5.3 ships Android APK and AAB artifacts. The latest default-branch commits checked on June 12 focused on NIP-17 direct-message handling, which is exactly the kind of maintenance a reader should want to see in a social client that touches private conversations.
That distinction helps the reader use Snort intelligently. If you only need a familiar feed, Snort can be judged like any social app: does it feel fast, can you find people, are messages readable, does the wallet flow make sense? If you care about Nostr as infrastructure, Snort is also worth inspecting as an implementation: which NIPs are supported, how NIP-46 is protected, how the worker relay stores data, how media uploads are signed and how the app chooses relays.
The surface readers actually touch
Snort's route structure shows the product that readers meet. The root tabs include a default feed, For You, Following, Followed by Friends, Conversations, Discover, tags, trending notes, trending hashtags, topics, media, follow sets, relay views, suggested profiles and an agent route. Beyond the tabs, the app includes event threads, profile pages, notifications, a free Nostr address page, a Nostr address page, messages, search, list feeds, a changelog, wallet pages and settings.
That spread is the shape of a mature social client. Snort is not just a post composer and a scrolling list. It gives you multiple ways to find people and notes, multiple entry points for public conversations, a media view, list-based feeds, direct-message routes, relay inspection and wallet flows. The app also has translation infrastructure through Crowdin, which is a quiet sign that the project has thought beyond one language community.
The product still feels closer to a power user's client than to a heavily managed mainstream network. That can be a strength. You see relays, signer choices, wallet connection strings, cache controls and Nostr-specific data types. Readers who want to learn the network may appreciate that transparency. Readers who want the protocol to disappear entirely may find Snort more technical than clients that hide nearly every Nostr concept.
Why the 0.5 line matters
Snort's release trail is unusually useful because it documents security and stability work rather than only cosmetic features. The Umbrel v0.5.3 listing highlights hardening around Schnorr signature verification, PIN encryption, NIP-46 relay-message forgery protection, secret leakage, NIP-26 delegation trust, unsafe JSON parsing, hanging promises and lifecycle or memory leaks. Those are not marketing bullets. They are the exact classes of bugs that matter in a browser-based Nostr client.
The same release line also mentions performance work: batched event verification in WebAssembly, lazy-loaded routes, precompiled translations, worker-relay optimizations and reduced duplicate verification. That tells you where Snort's complexity lives. A fast Nostr client has to verify signatures, query several relays, hydrate profiles, keep local cache state, render conversations and stay responsive when the network is noisy. The speed story is partly product design and partly low-level event handling.
For readers, the lesson is balanced. The existence of a hardening release means earlier code paths needed attention. It also means maintainers are looking directly at the right problems. When you choose a Nostr client, do not only ask whether it supports many NIPs. Ask whether the project fixes signer boundaries, invalid events, stale sessions, relay spoofing, wallet limits and cache bugs in public. Snort gives you a visible trail to inspect.
NIP support is broad, but the details matter
The README's support list covers a large part of everyday Nostr. Snort marks support for the basic protocol flow, contact lists, NIP-05 names, mnemonic key derivation, browser signing, event deletion, text-note threading, relay information, reposts, bech32 entities, nostr URI handling, long-form content, reactions, mentions, custom emoji, sensitive-content tags, user statuses, relay authentication, NIP-44 encryption, NIP-46 Nostr Connect, NIP-47 Nostr Wallet Connect, search, lists, live events, Android signing, zaps, badges, gift wrap, relay-list metadata, app-specific data, app handlers, DVMs, file metadata and HTTP auth.
A list that long is helpful, but it is not a guarantee that every feature is equally complete. Snort notes limited NIP-02 petname support and display-only behavior for delegated signing. The changelog also says NIP-4 direct messages were dropped in favor of NIP-17 in the v0.3 line, while older README text still includes NIP-04 support because encryption methods and legacy flows still appear in the stack. A careful reader should treat the list as a map, not as a final compatibility certificate.
The practical way to read Snort's NIP support is by use case. If you care about login, inspect NIP-07, NIP-46 and NIP-55. If you care about messages, inspect NIP-17, NIP-44 and gift wrap behavior. If you care about payments, inspect NIP-47 and NIP-57. If you care about discovery, inspect NIP-50, NIP-51, NIP-65 and NIP-89. Snort touches all of those areas, but the experience depends on the signer, relays, wallet and media servers you actually use.
Signing choices define the trust boundary
Snort's sign-in code supports a browser signer extension through NIP-07, Nostr Connect through NIP-46 on Android-detected environments and direct key input that accepts nsec, npub, NIP-05, hex or mnemonic formats. That menu matters. A Nostr client can be safe or risky depending on how it obtains signing authority. Signing with an extension or remote signer keeps the private key outside the web app. Pasting an nsec into a site gives that site far more responsibility.
The NIP-46 flow is especially important. Snort's code creates a nostrconnect URL with a generated secret, a relay and a permissions string. The system implementation documents both bunker URLs and nostrconnect URLs, notes that the secret is required in the client-initiated flow and verifies Schnorr signatures before processing NIP-46 messages from relays. The same file explicitly avoids logging decrypted parameters or results that may contain secrets. Those details are exactly where remote signing either becomes useful or becomes a trap.
Readers should still approve signer requests with care. A remote signer can reduce the need to paste keys into websites, but it can also sign real events if you approve too broadly. Snort's NIP-46 permission string includes signing several event kinds and NIP-04 encryption or decryption operations. Treat those as meaningful powers. Use a signer you trust, revoke old connections, avoid experimental sessions on a high-value identity and check whether your signer shows understandable prompts.
Relays are visible instead of hidden
Snort's default configuration names snort.social as the host and NIP-05 domain, includes a profile service at profiles.v0l.io and defines default relays including relay.snort.social, nostr.wine, relay.damus.io and nos.lol with read and write permissions that differ by relay. That is the kind of detail a reader should want to see. Relays are not background decoration in Nostr. They decide where your events are published, where your client reads and how quickly other people can find you.
The settings code gives users relay management rather than hiding the network behind one server. The relays page lists relay status, permissions and uptime, includes an add-relays textarea and tells users to aim for four to eight relays. The route structure also includes relay views, so relays become part of navigation and diagnosis, not just a hidden setup wizard. That makes Snort a good teaching client for people who want to understand why Nostr behaves differently from platform social media.
The tradeoff is that visible relays can be confusing. If you add too few relays, people may not see you. If you add too many, the app can become noisier and slower. If a relay requires authentication, payment or stricter policy, your client behavior changes. Snort gives the knobs, but the reader still has to learn them. A healthy setup is usually a small, deliberate relay set rather than a random pile of websocket URLs.
The worker relay makes Snort feel faster
One of Snort's more distinctive pieces is the worker relay. The package is named @snort/worker-relay and describes itself as a Nostr relay in a service worker. It uses SQLite WebAssembly in its build path, and the app's cache settings expose a Browser or Local Worker Relay, counts for cached data, a wipe action and a database dump named snort.db. There is also a Bun native SQLite relay package implementing the same cache-relay interface.
This design helps explain why Snort can feel responsive even when public relays are uneven. A local cache can store profiles, follow lists, gift wraps and events, then serve repeated views without fetching everything again. The system initialization also enables a follow graph and automatic outbox model. Those are serious product decisions: Snort is trying to make relay-based social data behave like a fast local application.
Local caching changes the reader's privacy and troubleshooting model. Cached data can make the app better, but it also means your browser may hold a meaningful local record of your Nostr activity. If the app behaves strangely, wiping the worker relay may fix stale state. If you are on a shared device, cache behavior matters. If you are debugging a missing note, remember that you may be looking at a mix of live relay data and cached results.
Messages moved toward modern encrypted DMs
Snort's messaging story has changed over time. The v0.3.0 changelog says the project dropped NIP-4 direct messages in favor of NIP-17 encrypted DMs and added NIP-44 v2 encryption. The README still lists NIP-04 because the codebase contains NIP-04 operations for some signer and legacy contexts. For readers, the key point is that Snort is not standing still on old-style encrypted direct messages.
NIP-17 private direct messages use gift-wrapped events and modern encryption patterns to improve on earlier direct-message approaches. In a social client, this changes both UX and trust. You want messages to be readable across clients that support the same modern flow, but you also want the client to handle decryption failures gracefully, avoid leaking secrets, keep relay behavior understandable and not accidentally make old DMs appear safer than they are.
The latest checked repository commit was a merge on May 29, 2026 involving NIP-17 decrypt-failure handling. That is a small but telling maintenance signal. Encrypted messaging bugs often show up in edge cases: missing keys, broken gift wraps, relay gaps, corrupted events, failed decryption and partial migrations from older DM formats. If private messaging is your main use case, test Snort with the exact people and signers you plan to use before relying on it for sensitive conversations.
Wallet features are present, but Snort remains a social client
Snort belongs in the social-client shelf, not the wallet shelf, but money is part of its product surface. The app has wallet routes for sending and receiving, a wallet settings area and a Nostr Wallet Connect settings page. The NWC UI accepts connection strings in the nostr+walletconnect family, asks the wallet for information, stores an active wallet configuration and links users toward Alby's NWC page as a setup path.
The @snort/wallet package parses nostrwalletconnect and nostr+walletconnect URLs, connects to the configured wallet relay and supports get_info and pay_invoice by default. It can also detect whether the connected wallet supports list_transactions, get_balance and make_invoice. The code handles relay authentication by signing a NIP-42 auth event and sends wallet RPC commands through NIP-47 event kinds. This is real wallet plumbing, not merely a zap button.
The reader should treat NWC like any payment permission. A connection string contains enough information for the client to talk to a wallet service through a relay. The wallet may enforce budgets, methods and approvals, but the app can request payments or invoices according to what the wallet allows. Use a wallet connection with small limits first, confirm which methods are supported, check transaction history and disconnect stale wallet sessions when you are done experimenting.
Media is handled through upload services and Blossom
Snort's media handling has moved beyond pasting image URLs. The v0.4.0 changelog says the project replaced NIP-96 uploads with Blossom storage and added media posts for newer event kinds. The upload code includes known upload services such as void.cat, nostr.build, nostrimg.com and nostrcheck.me, while the newer path uses Blossom uploads and mirrors through the blossom-client-sdk. The media settings page lets users maintain a Blossom server list.
The upload path computes file result metadata, uses a signed authorization event for upload, supports upload, mirror, list and delete actions and can add fallback URLs to NIP-94 metadata. That is the right direction for a Nostr media client: relays are not general-purpose file hosts, so the file itself needs a storage server while the signed event carries references, hashes and metadata. Snort's code makes that split explicit.
A reader should not confuse media signing with permanent control. A Blossom server can store and serve a blob, mirrors can copy it elsewhere and other clients can reference the same URL or hash. Deleting from one server may not remove every mirror. If you upload sensitive media, assume it can travel. If you care about resilience, use trusted media servers and mirrors. If you care about deletion, test deletion behavior before posting something hard to retract.
Discovery uses social graph, search and DVMs
Snort's discovery work sits across several layers. The tabs include For You, Followed by Friends, Discover, trending notes, trending hashtags, topics, media and follow sets. The changelog describes a personalized For You feed based on the social graph, Web of Trust spam filtering, DVM-powered trending posts and selectable content discovery DVMs. Those features are a response to one of Nostr's hardest problems: raw relay data does not automatically become a good reading experience.
The app package includes dependencies for search, graph visualization and data vending behavior. The README lists NIP-50 search, NIP-51 lists, NIP-89 application handlers and NIP-90 data vending machines. The v0.5 line adds display for DVM kind 7000 payment-required invoices, which matters because some discovery or AI-like Nostr services may charge for results. Snort is therefore both reading public events and participating in the wider service layer around them.
Readers should remember that discovery surfaces are opinions. A For You feed, Web of Trust filter, trending panel or DVM suggestion can help you find useful people faster. It can also hide things outside your graph, privilege particular relays or depend on paid or third-party computation. Use discovery as a map, not as the network itself. If you are researching a person, event or topic, compare Snort with another client and at least one search-oriented Nostr tool.
The developer packages are part of the Snort story
Snort's docs present the project as a set of TypeScript packages, not only as a hosted client. @snort/system is the core Nostr implementation with caching, querying and relay management. @snort/system-react provides React hooks and components. @snort/shared contains utility functions for keys, event signing and parsing. @snort/wallet handles Lightning wallet integration. @snort/worker-relay gives applications a service-worker relay.
The installation docs list Node.js 18 or Bun 1 as prerequisites and provide install paths for a minimal core setup, a React application, a full stack with wallet support and an all-packages setup. The important signal is architectural: Snort is modular enough for other builders to adopt pieces instead of copying the whole client.
This matters for readers because the Snort client is also a live demonstration of those packages under real load. If you are a developer, the app shows how the packages behave in production: route lazy loading, relay selection, query construction, worker-cache behavior, wallet RPC, signer abstraction and media upload. If you are not a developer, the package split still tells you something about maintainability. A client with reusable internal layers can fix protocol behavior in one place and share it across products.
What to test before relying on Snort
Start with identity and signing. Create or use a low-risk account, sign in through your preferred method, publish a harmless note, reply to someone, delete a test note and sign out. If you use NIP-07, confirm your browser signer shows readable prompts. If you use NIP-46, confirm the connection is revocable and that the permissions make sense. If you import a key directly, understand that the web app has far more responsibility for that key.
Next, test relays and cache behavior. Add one relay you know, remove one you do not need, check whether your relay list publishes correctly and compare a known event in Snort and another client. Visit the cache settings, note whether the Browser Worker Relay is active and understand the wipe or dump controls before you need them. If an event looks missing or stale, remember that relay state and local cache state can both be involved.
Finally, test money and media slowly. Connect an NWC wallet with a tiny budget and pay a small invoice or zap only after checking supported methods. Upload a harmless image, inspect the resulting URL, test whether another client renders it and look at your media server list. Send a low-stakes direct message to a trusted person and confirm both sides can decrypt it. These tests take less time than cleaning up a bad signer, wallet or media decision later.
Who Snort is best for
Snort is best for readers who want a fast, capable Nostr client and do not mind seeing the machinery. It is especially attractive if you care about relay control, signer options, search, follow-set navigation, media posts, wallet connection, zaps and modern encrypted messages. It gives enough product polish to be used every day and enough exposed structure to teach you how Nostr works.
It is also a strong reference point for builders. The project shows how to organize a large Nostr web app around reusable TypeScript packages, React hooks, a local worker relay, wallet abstractions, NIP-46, NIP-47, Blossom and a wide NIP surface. The changelog gives an honest look at the kinds of security and performance issues a production Nostr client has to solve. That is valuable even if you never use snort.social as your main client.
Snort is less ideal for readers who want the protocol completely hidden, or for people who do not want to think about signer choice, relay health, local cache, media storage and wallet permissions. Those concepts appear because Snort is close to the network rather than pretending Nostr is a single platform. If that is what you want, Snort remains one of the most useful social clients to study and one of the more revealing clients to use.
Sources worth opening
Start with the live client, repository, Zapstore manifest and docs, then read the code paths for routing, sign-in, NIP-46, NWC, worker relay, media uploads, settings and the NIPs Snort relies on.
- Snort live client
- Snort GitHub repository
- Snort README
- Snort Zapstore manifest
- Snort app changelog
- Snort v0.5.3 GitHub release
- Snort Google Play listing
- Snort Umbrel app listing
- Snort TypeScript library docs
- Latest Snort NIP-17 merge commit
- Snort app package file
- Snort root workspace package
- Snort default app configuration
- Snort app router
- Snort root tab routes
- Snort sign-in implementation
- Snort NIP-46 signer implementation
- Snort NWC settings page
- Snort Nostr Wallet Connect implementation
- Snort system initialization
- Snort cache settings page
- Snort worker relay package
- Snort Bun SQLite relay package
- Snort relay settings page
- Snort media server settings page
- Snort upload service code
- Snort Blossom upload code
- Snort moderation settings page
- Snort AI agent hook
- Snort TypeScript libraries docs
- Snort installation docs
- Official Snort Nostr profile
- NIP-07 browser signer capability
- NIP-17 private direct messages
- NIP-44 versioned encryption
- NIP-46 Nostr remote signing
- NIP-47 Nostr Wallet Connect
- NIP-50 search capability
- NIP-57 Lightning zaps
- NIP-65 relay list metadata
- NIP-89 recommended application handlers
- NIP-90 data vending machines
- NIP-94 file metadata
- NIP-98 HTTP auth
- Blossom specification repository
