CraysnoStrudel
noStrudel is a Nostr client for people who want to see more of the protocol than a normal social feed shows. It is a web app, PWA, Docker image and experimental mobile-capable codebase with signers, outbox routing, local caches, relay discovery, zaps, Blossom media, WebXDC apps and a Cashu wallet surface built into the same explorer.
A sandbox that became a full client
noStrudel is one of the clearest examples of a Nostr app that kept its experimental spirit while growing into a serious daily-use surface. The README still calls it a web app for exploring Nostr, and that wording matters. The point is not only to post notes, follow people and scroll a feed. The point is to expose the moving parts of Nostr in a way a curious user can touch: events, relays, signers, handlers, zaps, long-form posts, live events, media servers, lists and wallet backends.
The live site at `nostrudel.ninja` presents the app as noStrudel, with the description of a simple Nostr web client focused on exploring Nostr. Under the hood, the current repository is much larger than a minimal web client. The app routes include home notes, feeds, messages, profiles, note threads, polls, search, settings, relays, Blossom, notifications, pictures, streams, groups, tools, articles, bookmarks, lists, files, torrents, WebXDC, channels, goals, badges, emojis and wallet pages. The June 12, 2026 master branch removed the old NIP-54 wiki views, which is a useful signal: noStrudel keeps its workbench personality, but it trims features that become too complex or brittle.
For a reader, the practical question is whether that breadth helps or overwhelms. noStrudel is valuable when you want to inspect how Nostr behaves across different event kinds and different application layers. It is less ideal if you want the quietest possible onboarding client. The project gives you a lot of knobs because it treats Nostr as an open protocol space, not as one product lane. That makes it fascinating, but it also means a first session can feel more like opening a cockpit than opening a conventional app.
The maintainer is honest about risk
The most important line in noStrudel's README is the warning not to trust the app with your nsec. The project does support direct secret-key login, but the maintainer explicitly points out that a web client can be exposed to cross-site scripting risk and recommends using a browser extension such as Alby or Nos2x. That is not a minor footnote. It tells you how to approach the client safely: treat convenience and custody as separate decisions.
The sign-in code matches that warning. noStrudel can use a NIP-07 browser extension when `window.nostr` is available. It can use Nostr Connect through a QR or bunker URI. It can let you browse read-only by npub. It can accept a hex key, nsec or ncryptsec, with optional local password encryption for nsec. On Android it can register native signer support, and in browsers with serial support it can talk to signing devices over USB. The app gives power users several ways in, but the safest default for a normal browser session remains an external signer.
That choice affects everything else in the app. If you only read public events, an npub account is enough. If you post, react, zap, publish long-form content, sign WebXDC events or manage wallet data, the signer becomes part of the trust boundary. noStrudel is explicit enough that readers can make that decision deliberately. Use a disposable key for experiments, use a known signer for a real identity, and avoid pasting a valuable long-term nsec into a web page unless you have made a conscious tradeoff.
A modern PWA with self-hosting paths
The current noStrudel app is built with React 19, TypeScript, Vite and Chakra UI, with a service-worker PWA setup through VitePWA. The manifest declares noStrudel as a standalone social app, uses the green theme color `#8DB600`, and registers handlers for `web+nostr` and `nostr` links through `/l/%s`. That last detail is easy to miss, but it is central to the product. The app wants to be something you can open when a browser sees a Nostr reference.
The package file shows how broad the client has become. Alongside `nostr-tools`, it uses Applesauce packages for accounts, actions, common helpers, content, core, extra tools, loaders, React bindings, relays, signers, SQLite, wallet code and wallet-connect. It also carries `nostr-idb`, `nostr-wasm`, `@snort/worker-relay`, `nostr-social-graph`, `@cashu/cashu-ts`, `@getalby/bitcoin-connect`, `blossom-client-sdk`, WebLN, HLS, Leaflet, CodeMirror, EasyMDE, WebXDC types and Capacitor packages. A simple client would not need all of that.
Self-hosting is not an afterthought. The README gives a Docker command for running the image from GitHub Container Registry, and the Docker Compose file wires the app to optional local services: a cache relay, image proxy, CORS request proxy, Tor proxy and I2P proxy. The app's `index.html` exposes runtime flags for cache relay, image proxy, request proxy and proxy-first behavior. That makes noStrudel unusually interesting for readers who care about running a Nostr client as infrastructure instead of only visiting a public website.
Relay behavior is part of the product
noStrudel pays unusually close attention to relays. The constants define search relays such as `relay.nostr.band`, `search.nos.today`, `relay.noswhere.com` and `filter.nostr.wine`; lookup relays such as `purplepag.es`, `index.hzrd149.com` and Coracle's indexer; fallback relays through Primal, Damus and nos.lol; and NIP-66 discovery relays through nostr.watch and monitorlizard. Older builds also carried Wikifreedia-oriented wiki relay assumptions, but current master has removed the wiki feature. The remaining defaults still reveal the app's operating model: Nostr discovery is a relay problem first.
The event-cache service is another sign of that seriousness. noStrudel can read and write events through a local relay, IndexedDB, a hosted relay mode, no cache, and on native builds a SQLite cache. It buffers writes, marks cached events and prunes IndexedDB based on a maximum event setting. The Docker path can provide a local relay cache instead of relying only on the browser cache. This matters because a broad Nostr client can become slow or inconsistent if it re-fetches everything from public relays on every view.
The project also includes NIP-66 relay discovery code. It subscribes to monitor-stat events, caches recent relay metadata, and can filter relays by supported NIPs, network or country tags. That does not magically solve relay selection, but it makes relay selection visible. It also explains why noStrudel can feel more technical than polished social apps: relay health, outbox routing, cache selection and relay authentication are not hidden problems. They are surfaces a curious user can inspect and tune.
Outbox routing changes the feed model
The noStrudel changelog for version 1.0.0 marks a major shift: subscribing to users' outbox relays for the home feed. That is a meaningful architectural milestone. A naive Nostr client asks a fixed set of relays for everybody. An outbox-aware client tries to follow where each author says they publish and read, usually through NIP-65 relay list metadata and related discovery logic. The result can be a more complete feed with fewer unnecessary relay connections.
The source includes an outbox cache service that builds outbox maps for lists and caches them, plus an outbox subscription service that routes subscriptions through those maps. The app also exposes settings for maximum connections and maximum relays per user. These details matter because feed reliability in Nostr is not only a UI question. It depends on whether the client can find the right relays for the people, lists or communities you care about.
This is also where noStrudel's open issues become useful reader context. One open issue from December 2025 says relay connections are not stable, and another requests stronger privacy behavior through relay inception. Those are not disqualifying defects; they are a reminder that Nostr clients live in a hard network environment. noStrudel is active and ambitious, but relay behavior should still be tested before you rely on it for a single important feed.
Feeds are only one surface
The ordinary social pieces are present. noStrudel has timelines, profiles, note detail pages, notifications, reactions, reposts, quote posts, hashtags, mutes, mentions, polls, direct messages, lists and search. It can show articles in a dedicated long-form view, use text-to-speech for article reading where browser speech synthesis exists, display comments, show zaps, render markdown, embed media and use Nostr links. It can be used as a normal Nostr social client if that is all you need.
The wider app map is what separates it from a basic client. Streams use live-event kinds and can show live, planned and ended events. WebXDC support lets a user publish `.xdc` apps as kind 1063 file metadata with the `application/x-webxdc` MIME type, a hash tag and a `webxdc` coordination id, then open app pages with persistent and realtime update events. The project previously explored NIP-54 wiki pages and Wikifreedia-style topic pages, forks and defers, but the June 12, 2026 master branch removed those views because they were too complex for this client. Those surfaces are not decorative. They show what a general Nostr client can become once it treats event kinds as application modules.
There is a tradeoff. Every extra surface brings protocol nuance, relay coverage questions, moderation questions and maintenance burden. noStrudel has removed some broken or inactive features over time, including old DVM tools, experimental relay chat, video views and certain badge or goal views. That history is healthy. It shows the app is maintained by subtraction as well as addition. A reader should expect a living client, not a frozen showcase where every experimental feature remains forever.
Blossom and file handling are first-class
noStrudel's media story has moved beyond simple image URLs. The app includes Blossom routes, Blossom server links and server favicons, user media server hooks, blob details, multi-server upload helpers and settings for media upload behavior. The helper code creates Blossom upload authorization with the user's signer and can upload to multiple servers, falling back for media where appropriate. That is the kind of plumbing a serious media-aware Nostr client needs.
The app still keeps older media assumptions around. Default app settings list `nostr.build` as the media upload service, and parts of the app deal with image proxying, CORS proxying, open graph data and media safety based on social graph distance. The README's Docker configuration can wire an image proxy and request proxy into a self-hosted deployment. In a protocol client, media is not just a file picker. It is storage, authorization, caching, safety, thumbnails, mirroring and broken-link handling.
For a reader, the practical advice is simple: inspect your media-server settings before uploading anything important. Blossom can make media more portable and signer-authenticated, but upload servers still have policies and availability. If you use noStrudel to share files, WebXDC packages, images or video, remember that the signed Nostr event and the actual bytes live in different places. A good client can connect them. It cannot guarantee that every storage host will keep them forever.
The wallet surface is real but experimental
noStrudel now has a wallet route and wallet settings, but it should not be mistaken for a conservative Bitcoin wallet. The app can auto-detect WebLN, persist Nostr Wallet Connect wallets, and load an active account's NIP-60 Cashu wallet through Applesauce's NutWallet. The wallet service presents all usable backends through a common interface: get balance, make invoices, pay invoices, list history where possible and refresh state. That is a serious product surface.
The warning in the wallet view is blunt: the Cashu NIP-60 wallet is experimental and unstable, and the user should not put funds into it that they are not willing to lose. That sentence belongs in any reader's mental model. The NIP-60 path ties ecash token events and history to the user's Nostr account and relays. It supports mints, relays, token sending, token receiving, QR display, history entries, deletion requests, consolidation, syncing, recovery from a local couch and optional auto-unlock. That is powerful, but it is also a lot of moving parts for money.
NWC support is more conventional for a social client. The app can add a Nostr Wallet Connect wallet by QR auth flow or by pasted connection string. It requests methods such as balance, info, invoice creation and invoice payment, and it defaults the wallet-auth relay to Alby's relay. It also includes a migration path from older bitcoin-connect NWC storage. Use a wallet with strict budgets, test with tiny amounts, and remember that a Nostr client is not the same trust category as a dedicated wallet.
Zaps, goals and payments are connected to content
Payments in noStrudel are not isolated in the wallet page. The article view, goal view, file view, note view and other surfaces can expose zap buttons and zap bubbles. The zap modal builds NIP-57 zap requests, uses recipient Lightning metadata, handles zap splits, includes event or address tags where needed, signs the zap request and then hands payment to the active wallet backend or manual invoice flow. That is the normal Nostr payment pattern made visible across the app.
The app settings still include custom zap amounts, auto-pay-with-WebLN history and Lightning display preferences. The wallet backend can pay a bolt11 invoice through WebLN, NWC or the experimental NIP-60 wallet. When a WebLN wallet cannot emit a paid event, noStrudel watches for a balance increase. For NWC it listens for payment notifications. For Cashu it mints or melts ecash through configured mints. Those are different trust models under the same button.
That is why payment testing should be slow and boring. Send a tiny zap first. Confirm which backend is active. Check whether the invoice came from the expected recipient. If you have NWC connected, confirm its budget and permissions in the wallet. If the Cashu wallet is enabled, understand which mint holds the balance and where wallet events are stored. noStrudel can make content payments feel seamless, but the route from button to money still crosses signers, relays and wallet services.
Private messages and encrypted caches need attention
noStrudel supports modern private-message work as well as older encrypted-direct-message patterns. The changelog around version 0.45 mentions NIP-17 group messages, message cache work, redesigned direct messages, DM conversation info and an inbox for decrypting messages. The decryption-cache service can store decrypted content locally, optionally behind encrypted storage, and can auto-decrypt legacy messages or gift wraps when the active account is involved.
That improves usability, but it also introduces local-device questions. A message cache can make a client faster and less annoying. It can also leave sensitive content on a machine if the user does not understand cache settings. noStrudel exposes preferences for enabling the decryption cache, encrypting it, using an encryption salt and clearing it when settings change. This is the kind of detail readers should check before using a shared computer or a browser profile they do not fully control.
The broader privacy settings also matter. noStrudel can hide events outside a social graph distance, blur media outside the graph, hide embeds, use relay authentication preferences, choose proxy behavior and tune media policies. None of this makes a public Nostr identity private by default. It gives a careful user more control over what the app fetches, shows and stores. For sensitive use, start with read-only mode or a separate key and inspect the settings before signing messages.
Version 1.1.0 and the June 12 cleanup show active maintenance
As of June 12, 2026, the GitHub repository showed version 1.1.0, tags through v1.1.0, an MIT license and active development. The current top commit removed the NIP-54 wiki feature and views, saying they were too complex for this client and let the project drop several wiki-only dependencies. The recent changelog still matters: it includes notification splitting, random anonymous default pubkeys, outbox feed changes, NIP-29 group work, Blossom server pages, article reader work, relay feed additions, NIP-17 direct-message improvements and many removals of broken experiments.
Open issues give a more realistic picture than marketing copy. Recent items include Nostr Connect QR login hanging due to an EOSE timeout, relay instability, wording improvements, NIP-05 and LNURL validation changes, account behavior across tabs, tagging responsiveness and requests for stronger privacy options. Those issues tell you the project is alive, but they also tell you where to test carefully. A protocol-heavy client can be maintained and still have rough edges.
The project is also framed as personal work. The README says there are many missing features and asks contributors to keep pull requests small. That matters for expectations. noStrudel is not a venture-backed app with a support desk. It is a capable open-source client that moves quickly because a maintainer is willing to explore. Readers should value that, but they should also keep backups of keys, use external signers and treat experimental wallet features as experimental.
Who should open noStrudel first
noStrudel is a strong first stop for technically curious Nostr users. If you want to understand how Nostr feels when a client exposes more than a feed, open noStrudel. Use it to inspect a note, follow relay behavior, open a long-form article, look at streams, browse lists, test app handlers, check Blossom media settings, add a read-only account and compare how different signers behave. It rewards curiosity.
It is a less comfortable first stop for someone who only wants a polished social app with minimal decisions. The account choices, relay settings, cache settings, wallet warnings and many routes are useful, but they can make the app feel busy. A new user may be better served by a narrower mobile or web client first, then return to noStrudel once they want to understand why Nostr behaves differently from platform social networks.
For builders, noStrudel is worth reading in source form. The codebase shows how a modern Nostr client can wire React, Vite, PWA support, NIP-07, NIP-46, NIP-47, NIP-60, NIP-65-style outbox ideas, NIP-66 relay discovery, NIP-17 messages, NIP-57 zaps, NIP-89 handlers, NIP-96-adjacent storage, Blossom uploads, WebXDC, historical wiki-event code and local caches into one app. It is not a reference implementation in the formal sense. It is better than that for readers: a living map of what real Nostr app work looks like when the protocol keeps expanding.
App handlers make the protocol feel navigable
One of noStrudel's most useful details is easy to overlook: it treats Nostr links and recommended application handlers as part of the reading experience. The Vite PWA manifest registers protocol handlers for `web+nostr` and `nostr`, while the app-handler modal can look up handler information events and offer ways to open a profile, note or other event in another app. That means noStrudel is not trying to trap every action inside itself. It can act as a launch surface for the wider ecosystem.
That matters because Nostr is full of portable identifiers that need context. A reader sees an npub, note, nevent, naddr or coordinate, but the right application depends on the event kind and the user's intent. A long-form article might belong in a reader. A file metadata event might belong in a media tool. A wallet request belongs nowhere near a normal timeline. noStrudel gives the user enough event visibility to understand that difference, and then enough linking behavior to move to another tool when that is better.
This is also a quiet education layer. Many clients hide raw event details because they want to feel simple. noStrudel keeps debug buttons, event views, app handler choices, NIP labels and routing surfaces close enough that a reader can learn how the protocol is assembled. You do not have to become a developer to benefit. You only need to notice that a Nostr object has a kind, tags, relays and sometimes a preferred handler. Once that becomes visible, the whole network feels less like magic and more like a readable set of records.
Search and identity lookup are deliberately plural
Search in noStrudel is not a single box backed by one private database. The constants and settings point to several search and lookup paths: search relays such as nostr.band, nos.today, noswhere and filter.nostr.wine; recommended lookup relays such as purplepag.es, hzrd149's index and Coracle's indexer; username lookup through Primal, Vertex and Relatr paths added in the changelog; plus direct decoding of Nostr identifiers. That plural design reflects Nostr's reality. There is no one search authority that sees everything and ranks everything forever.
The read-only sign-in path shows the same idea from another angle. A user can enter a name, npub or hex key, and the app can normalize direct pubkeys or ask lookup services for likely profiles. That is practical because readers often arrive with partial identity information. They may know a handle, an npub, a NIP-05 name, or a link copied from another client. noStrudel gives enough entry points that a user can find a profile without immediately handing over signing authority.
The limitation is that search quality is always conditional. Relays may not support NIP-50 search. Indexers may weight the network differently. NIP-05 names can be stale or misconfigured. Lightning addresses can fail validation. noStrudel exposes more providers and settings than many clients, but it cannot make identity and search global in a network designed to avoid a single global database. Treat search results as a map, not as the territory, and compare important lookups in more than one client.
The interface is shaped by maintenance choices
The changelog tells a story that the interface alone cannot. noStrudel has added features aggressively, but it has also removed features that were broken, inactive or not worth carrying. Version 1.0.0 removed broken DVM tools, experimental relay chat, certain video views, badge browsing and old note-correction support, and the June 12, 2026 master branch removed the wiki feature for the same maintenance reason. Earlier releases changed navigation, rebuilt notifications, redesigned direct messages, added and then refined local cache options, changed how threads load, and repeatedly fixed mobile layout issues. That history explains why the app can feel both broad and opinionated.
This matters for a reader because Nostr apps often age in public. A feature may look stable because it appears in a menu, but the underlying relay habit, event kind or supporting service can change. noStrudel's removals show a maintainer willing to prune when a surface no longer works. That is better than keeping dead buttons for nostalgia, but it also means the app's shape can change between visits. A page that exists today may move, a feature may be rethought, and a setting may be renamed as the protocol stack changes.
The right expectation is not perfection. The right expectation is active, inspectable iteration. noStrudel publishes its code, tags versions, keeps a changelog, exposes issues and ships Docker and PWA paths for people who want more control. That makes the project unusually transparent. It also makes the reader's job easier: before trusting a feature, you can look at the current issue list, check the last push, read the relevant source file and test the feature with a low-risk key or tiny payment.
What to test before relying on it
Start with identity. Use read-only npub mode or a test key first. Then try NIP-07, Nostr Connect or another external signer if you want to post. Avoid using a valuable nsec directly in the web app until you are comfortable with the risk. Check whether the signer prompts make sense, whether the app has the permissions you expect and whether logging out removes the account from the device state you care about.
Next test relays and cache. Open your home feed, a profile, a thread, search, articles and streams. If something is empty, compare with another client before assuming the event does not exist. Change relay and cache settings only after you understand what they affect. If you self-host, test the Docker image with a cache relay, image proxy and request proxy in a low-risk environment first.
Finally test money and media with tiny stakes. Connect an NWC wallet with limits, send a tiny zap, and check the wallet history. If you enable the Cashu wallet, create a small test balance and learn where mints, relays, token events and history are displayed. If you upload media or WebXDC packages, confirm which Blossom or media servers receive the file. noStrudel gives you excellent visibility, but visibility is not a substitute for cautious first use.
Sources worth opening
The useful reading path starts with the live site, README, current GitHub metadata, package file, changelog and Docker configuration, then follows the source files for signers, wallets, cache, relay discovery, Blossom, WebXDC, streams, articles and the NIPs those surfaces depend on.
- noStrudel live site
- noStrudel GitHub repository
- noStrudel README
- noStrudel package.json
- noStrudel CHANGELOG
- noStrudel June 12, 2026 wiki-removal commit
- noStrudel Vite PWA configuration
- noStrudel Docker Compose example
- noStrudel Zapstore manifest
- noStrudel Capacitor configuration
- noStrudel app routes
- noStrudel constants and default relays
- noStrudel account service
- noStrudel sign-in start view
- noStrudel Nostr Connect sign-in
- noStrudel private-key sign-in
- noStrudel wallet service
- noStrudel NWC migration service
- noStrudel wallet view
- noStrudel wallet settings
- noStrudel add-wallet modal
- noStrudel Cashu token tab
- noStrudel Cashu token send modal
- noStrudel Cashu token receive modal
- noStrudel event cache service
- noStrudel IndexedDB event cache
- noStrudel native SQLite event cache
- noStrudel NIP-66 relay discovery
- noStrudel outbox cache
- noStrudel outbox subscriptions
- noStrudel relay info service
- noStrudel decryption cache
- noStrudel Blossom upload helper
- noStrudel WebXDC helper
- noStrudel WebXDC publishing view
- noStrudel v1.1.0 wiki helper (historical)
- noStrudel articles view
- noStrudel article page
- noStrudel streams view
- Nostr NIPs repository
- NIP-07 browser signer
- NIP-17 private direct messages
- NIP-46 Nostr remote signing
- NIP-47 Nostr Wallet Connect
- NIP-54 wiki
- NIP-57 Lightning zaps
- NIP-60 Cashu Wallet
- NIP-65 relay list metadata
- NIP-66 relay liveness monitoring
- NIP-89 recommended application handlers
- NIP-96 HTTP file storage integration
- Blossom specification repository
- Cashu TypeScript library
- Applesauce wallet-connect package
- Zapstore
