CraysNotedeck
Notedeck is a native Nostr browser from the Damus orbit: a Rust client built around decks, columns, nostrdb, account management, zaps, Nostr Wallet Connect, messaging work and Dave, an AI assistant that lives inside the same app framework.
A native Nostr browser from the Damus orbit
Notedeck comes from the same public development world as Damus, but it should be read as its own client rather than as a simple desktop port. The official Notedeck page presents a fast native Nostr experience for Linux, Windows and macOS, while the current README describes a modern multiplatform Nostr client built with Rust for desktop and Android. The GitHub repository description is shorter and sharper: Notedeck is "The nostr browser." That phrase is useful because it frames the app as something broader than a timeline.
A browser for Nostr has to do more than render kind 1 notes. It has to open profiles, threads, search results, notifications, people lists, custom filters, relay views, wallet views, account views and support screens without making every view feel like a separate app. Notedeck's route system exposes that ambition: timelines, threads, accounts, relays, settings, compose, search, wallet, zap amount customization, welcome, terms and report routes all live inside the same navigation model.
The project is also not trying to hide that it is still young. The public site has older alpha-era language in places, the README says beta, and the latest GitHub releases show prerelease names. That does not make Notedeck unimportant. It makes it a useful signal of where native Nostr client work is going: local databases, real account storage, stronger desktop ergonomics, Android support and protocol features that feel too heavy for a lightweight web client.
The beta label matters
As of June 12, 2026, Notedeck's GitHub repository had recent activity, hundreds of open issues and a latest listed release named `v0.10.0-beta.4`. The release was published on April 21, 2026 and exposed an APK asset, while the prior beta releases included desktop packages for Linux, macOS and Windows. That release pattern says two things at once: the project is not abandoned, and the exact distribution experience is still moving.
The open issue list makes the same point in a practical way. Recent issue titles mention push notifications, initial Purple integration, video direction, discovery and algorithmic feeds, Android keyboard behavior, tagging after newlines, onboarding lists, retrying failed posts, foldable device behavior, outbox correctness and message notification indicators. These are not abstract roadmap wishes. They are the kind of rough edges a user notices when a client moves from interesting prototype to daily application.
A reader should therefore approach Notedeck as a serious beta rather than as a finished replacement for every other Nostr client. Install it if you want to test a native client with strong local architecture, multiple columns and unusually active protocol work. Keep another client nearby if you need a stable fallback for posting, messages, wallet operations or mobile use. The right expectation is active development, not quiet polish.
Decks, columns and local speed
The most visible Notedeck idea is the deck. The `notedeck_columns` crate is built around decks, columns and timelines: a deck is a collection of columns, and a column is a view into a specific type of Nostr content. That makes Notedeck feel closer to a monitoring console than to a single infinite feed. You can think in terms of contact lists, notifications, profiles, searches, hashtags, people lists, custom filters and last-notes-per-pubkey views rather than one master timeline.
That design only works if the client can keep local state fast. Notedeck leans on `nostrdb`, the embedded Nostr database associated with the Damus ecosystem, for efficient local storage and queries. The core developer documentation describes a data layer built from NostrDB, a note cache for expensive note structure, image and GIF caching, an outbox pool for relay connections and an unknown-ids layer for resolving profiles and notes. The point is not only speed. It is continuity: a native app can hold more state than a throwaway tab.
The timeline model is also richer than a home feed. Source code for `TimelineKind` includes contact lists, NIP-51 people lists, search queries, notification timelines, profiles, the universe feed, hashtags, generic filters and a last-per-pubkey algorithmic view. Some views subscribe locally and remotely in realtime, while others are treated as refreshable or cache-dependent. That is exactly the kind of detail a column client needs, because each column can have different freshness and relay behavior.
Accounts, keys and the OS keyring
Account handling is one of the areas where a native client can feel meaningfully different from a web app. Notedeck's account model stores a user keypair, account data and optionally a zap wallet. The login UI accepts public keys, private keys and Nostr addresses, while the account code serializes account state and wallet state. That makes account switching part of the product instead of a bolted-on browser-session trick.
The sensitive part is private-key storage. Notedeck includes a keyring store with the service name `com.damus.notedeck`, and the workspace dependencies select native keyring support for Apple, Windows and Linux, plus Android keyring support. In plain reader terms, the project is trying to use the operating system's credential storage rather than leaving everything as a loose text file. That is the correct direction for a native Nostr app, especially if it asks users to sign real events.
It is still worth being conservative. A native keyring is better than casual browser storage, but it does not make a beta app risk-free. Use a test key first. Learn how the app adds, selects and removes accounts. Check whether a wallet connection is global or account-specific. If you plan to use a long-term Nostr identity, make sure you understand where the key lives on that device and how you would recover or revoke access if the machine were lost.
Relays are working infrastructure
Notedeck treats relays as something the user should be able to see and manage. The route system includes a relay screen, the side panel has a connectivity indicator, and relay UI code distinguishes advertised relays from other connected outbox relays. The core documentation also points to `RelaySpec`, including NIP-65-style read and write markers. That matters because Nostr feed reliability is often a relay problem before it is a rendering problem.
The timeline code shows the relay relationship more concretely. Contact-list timelines query local NostrDB first and ask for remote data when the required contact list is missing. Profile timelines split local and remote work so notes, reposts, metadata and contact lists can be fetched with different filters. Notification filters look for notes, reactions, reposts and zap receipts. Hashtag and generic timelines can break if the filter is empty, and the code treats those cases explicitly rather than pretending every query is valid.
This is the part of Notedeck that will appeal to users who have outgrown a single default relay list. A column client becomes genuinely useful only if it can show several slices of the network while keeping relay state understandable. The remaining question is not whether Notedeck knows relays matter. It clearly does. The question is how quickly the beta can turn that awareness into a predictable daily experience across home feeds, search, people lists, notifications and mobile connections.
Zaps and Nostr Wallet Connect inside the client
Notedeck has real Lightning zap plumbing, not just a decorative zap button. The core developer documentation describes a flow that creates a kind 9734 zap request, fetches a Lightning invoice through LNURL or LUD-16, pays the invoice through a connected wallet and tracks zap state. The wallet code uses the NWC crate and parses `nostr+walletconnect` URIs into Nostr Wallet Connect clients that can check balance and pay invoices.
The implementation is careful in places that matter. The zap networking code checks whether the LNURL endpoint allows Nostr zaps, validates the endpoint's Nostr pubkey shape, enforces min and max sendable amounts, builds the zap request and asks the wallet backend to pay. The zap verification code then works on receipts by checking the referenced note author rather than blindly trusting a `p` tag on note zaps. That is the kind of defensive detail readers should want in payment-adjacent client code.
Still, Notedeck is not a dedicated wallet. The wallet surface exists to let a Nostr client perform zaps and related payment actions through NWC, not to replace a Lightning wallet with budgeting, controls and backup education. Use small amounts while testing. Prefer wallet connections that support spending limits. Confirm which account has which wallet attached. If a zap fails, treat the failure as a client, relay, LNURL or wallet-path question rather than as one simple button error.
Messages, giftwrap and the private side
Notedeck's messaging work is one of the places where the repository is more informative than the public site. The workspace includes a `notedeck_messages` crate, tests for relay delivery, giftwrap delivery, multi-relay delivery and NIP-77-aware test relays, plus code around kind 10050 DM relay lists. Recent issues and pull requests mention grouped notifications, zap receipt verification, Nostr double-ratchet direct messages and message notification dots.
The code points toward modern private-message patterns rather than old one-off encrypted DMs. NIP-17 private direct messages, NIP-44 encryption, NIP-59 gift wraps, kind 10050 relay-list discovery and negentropy-style sync all appear in the relevant development surface. That does not mean every future-facing message feature is finished for normal users. It does mean Notedeck is being built with the newer Nostr messaging stack in mind.
For a reader, the practical advice is to separate protocol ambition from daily trust. Private messaging in Nostr depends on keys, wrapping, relay choice, local storage, notification behavior and multi-device sync. A native client can improve that experience, but it can also hold more local history. Before using Notedeck for sensitive conversations, test basic sending, receiving, notification behavior, device sync and local data removal with a non-sensitive account.
Dave turns the app into a programmable surface
Dave is the oddest and most revealing piece of Notedeck. The README describes Dave as an AI assistant for Nostr built as a Notedeck application. Its own documentation gives it two roles: a conversational interface for querying Nostr data and an agentic development environment with Claude Code integration. In other words, Dave is not just a chatbot bolted beside a feed. It is an example of Notedeck as an application framework.
The Dave docs list natural-language conversations, local Nostr database queries, tool-based AI actions, multiple AI providers, OpenAI, Anthropic and Ollama chat modes, plus a Claude Code agentic mode with sessions, permissions, diff views, command execution, file browsing, focus queues and subagents. The configuration code includes provider and model settings through environment variables such as `OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, `DAVE_MODEL` and related backend controls.
That direction is exciting, but it should be read carefully. An AI assistant that can query local Nostr data may be useful for finding notes, summarizing context or building new app surfaces. An agentic coding mode is a different trust category, especially when it can inspect files and ask for tool approvals. Dave is valuable because it shows how Notedeck can host more than one Nostr application. It also asks users to think clearly about local data, AI providers and permissions.
Updates are being tested through Nostr itself
Notedeck contains one of the more interesting pieces of app-infrastructure code in the ecosystem: a release tool and updater built around NIP-82-style software distribution events. The `notedeck_release` README describes a CLI that publishes software asset events and software release events. Those events can include the app identifier `com.damus.notedeck`, artifact URLs, SHA256 hashes, versions, platform tags, MIME types and sizes.
The updater code subscribes to release and asset events in NostrDB, filters by a trusted release pubkey, checks release channels such as main, beta, nightly and dev, chooses a platform asset, downloads it, verifies the SHA256 hash and stages it for installation. That is a very Nostr-native way to think about app updates: release discovery is signed and distributed through the same event network the client already understands.
The source also contains a caution that should not be ignored: the default release signing pubkey is marked with a TODO to replace it before shipping. That means readers should not overstate the updater as a finished trust system. The important point is the direction. Notedeck is experimenting with software distribution as signed Nostr data, while still needing the normal operational discipline of release keys, channels, platform packages and restart behavior.
Moderation and user safety are local realities
Notedeck's public legal and compliance documents are unusually direct about Nostr's limits. The EULA text explains that Nostr content can be replicated across independent relays, that the app does not control most relays, and that published content may not be fully removable everywhere. It also says blocking and muting affect the user's local view rather than preventing others from seeing public content on the wider network.
The UGC compliance plan is equally useful for understanding the client. It lists existing client-side muting for pubkeys, hashtags and threads, plus blurhash media obfuscation for non-followed users. It then names planned or required safety pieces such as terms acceptance, blocking, reporting, age verification, NIP-56 reports and content-and-safety settings. Some of those pieces are visible in the routing and UI work, including terms and report routes.
This is the right tone for a Nostr client. A user should not be told that decentralization magically solves abuse, spam or illegal content. A native client can provide mute lists, block lists, reporting, local media handling, warnings and account-level controls. It cannot delete every copy of a public event from every relay. Notedeck is worth watching partly because its documentation admits that line instead of hiding it.
Who should use Notedeck first
Notedeck is strongest for people who want a native, multi-column Nostr environment and are comfortable with beta software. If you already understand relays, zaps, signers, accounts and the difference between local state and remote events, Notedeck gives you a lot to inspect. It is especially interesting for users who want a desktop client that can grow beyond a feed into a working Nostr console.
It is also interesting for developers. The repository is a living map of one serious Rust Nostr application: egui and eframe for the interface, nostrdb for local event storage, outbox pools for relay work, NWC for wallet actions, NIP-17-style message work, NIP-82 updater experiments, Fluent localization, Android GameActivity support and a modular app container. Reading the code can teach more than a polished marketing page would.
For a brand-new Nostr user, Notedeck may not be the first client to open. A narrower mobile client or simpler web client can be less intimidating. But once a user starts asking why a feed is incomplete, why a zap failed, where a key is stored, why messages need relay lists or how local databases change performance, Notedeck becomes useful. It exposes the work a serious client has to do.
What to check before relying on it
Start with account safety. Install the current release from the official path, try a test account, and confirm how account creation, import, switching and removal behave on your platform. Check whether the app stores secrets in the OS keyring and whether that matches your expectations for the machine you are using. Do not make your most valuable key the first key you test in a beta client.
Then test the client surfaces that matter to you. Open a home-style contact timeline, a profile, search, notifications, a hashtag column, a people list and relay management. Compare a few important profiles or threads with another client. If something is missing, it may be a relay-list, filter, cache or subscription issue rather than missing content. A multi-column app is only as useful as the relay behavior behind each column.
Finally test money and messages slowly. Connect an NWC wallet with strict limits, send a tiny zap, confirm the invoice path and check whether the receipt is recognized. For messages, send low-risk test conversations across devices and relays before using it for anything private. Notedeck's direction is compelling, but the safest way to enjoy a serious beta is to make every risky surface boring before it becomes routine.
Sources worth opening
A useful reading path starts with the official Notedeck page and install page, then follows the GitHub repository, README, release history, changelog, core developer docs, source files for accounts, zaps, updater and messages, and the NIPs behind the features.
- Notedeck official page
- Notedeck install page
- Notedeck GitHub repository
- Notedeck README
- Notedeck Cargo workspace
- Notedeck changelog
- Notedeck GPL license
- Notedeck security policy
- Notedeck v0.10.0-beta.4 release
- Notedeck v0.10.0-beta.3 release
- Notedeck v0.8.0-rc2 release
- Notedeck core developer documentation
- Notedeck Chrome developer documentation
- Notedeck Columns developer documentation
- Dave AI assistant documentation
- Notedeck release tool documentation
- Notedeck UGC compliance plan
- Notedeck EULA
- Notedeck timeline kinds source
- Notedeck route source
- Notedeck wallet source
- Notedeck user account source
- Notedeck OS keyring source
- Notedeck zap networking source
- Notedeck zap verification source
- Notedeck zap parsing source
- Notedeck Nostr updater source
- Notedeck updater state source
- Notedeck NIP-17 messages source
- Notedeck relay delivery tests
- Notedeck account login view
- Notedeck relay view
- Notedeck settings view
- Notedeck open issues
- Notedeck pull requests
- nostrdb repository
- nostrdb-rs repository
- egui project
- Rust Nostr crate
- NWC crate on crates.io
- Nostr NIPs repository
- NIP-17 private direct messages
- NIP-44 versioned encryption
- NIP-47 Nostr Wallet Connect
- NIP-56 reporting
- NIP-57 Lightning zaps
- NIP-59 gift wrap
- NIP-65 relay list metadata
- NIP-77 negentropy syncing
- NIP-82 software distribution
- Crowdin Notedeck translations
