CraysLume
Lume is a desktop Nostr client with two visible lives: the released Tauri app for macOS and Windows, and a newer Rust/GPUI reboot in the public repository. It is a useful window into what a serious desktop client has to handle: accounts, signers, key storage, relays, local databases, columns, zaps, media, sync, notifications and the rough edges that show up when Nostr moves from phone feeds into workstation software.
A desktop client with two public eras
Lume is best understood as a desktop Nostr client, not a mobile social app and not a web-only experiment. The released v24.11.8 generation presents itself as a free and open-source client for macOS and Windows 11, with GitHub release downloads for DMG, MSI and Windows setup builds. The screenshots linked from that README show the expected app surfaces: login, welcome screen, newsfeed, thread view and dark mode.
The current repository tells a second story. The master branch has a tiny README that says the project is rebooting, and the codebase has shifted into a Rust workspace built around GPUI, Zed-derived GPUI dependencies, rust-nostr, LMDB and a new application shell. The latest public commits on master in December 2025 mention project structure, workspace, account state, event handling, onboarding and a simple login process. That looks like an active rewrite rather than a polished user release.
A reader should not collapse those eras. The Tauri generation is the released product that users could install in late 2024. The Rust/GPUI branch is the forward-looking public work that shows where the maintainer wants to take Lume. The honest article has to hold both at once: Lume is real enough to have desktop releases and deep code, but unstable enough that the current source tree is not simply the same thing as the downloadable v24.11.8 app.
What the v24 release actually shipped
The v24.11.8 release was published on November 11, 2024. Its release note is short but specific: it added Sync All via Negentropy in settings, improved notification messaging and improved text visibility in settings. The release assets include macOS builds for x64, aarch64 and universal app packages, DMG installers, Windows MSI and setup files, signatures and a `latest.json` updater manifest. That distribution pattern is ordinary desktop-app work, not just a demo ZIP.
The surrounding v24 release history shows an unusually fast iteration month. v24.11.0 added multi-account support, NIP-51 follow-set discovery, NIP-51 interest-set discovery, a relay viewer column and Windows 10 support. Later releases in the same week fixed Windows startup crashes, added a tray icon, improved Nostr Connect, added DVM feeds, allowed custom relays for relay feeds, moved toward better dark-mode visibility and added Negentropy sync behavior. The app was actively adjusting real desktop friction.
That matters because Lume is not merely a timeline clone. Its release notes show work on desktop persistence, windows, tray behavior, performance, sync, custom columns, signer flows and discovery surfaces. Those are the unglamorous parts that decide whether a Nostr client can live on a laptop all day. A phone client can hide behind a single scrolling feed. A desktop client has to deal with window state, background sync, notifications, columns and multiple accounts without becoming noisy.
The old homepage is not the anchor anymore
The v24 Tauri configuration still lists `https://lume.nu` as the bundle homepage and uses the app identifier `nu.lume.Lume`. During current research on June 11, 2026, that domain did not resolve from the local network. That does not erase the project, because GitHub remains active and release files remain available, but it changes what a careful reader should treat as primary. The repository and releases are stronger sources than the dormant homepage.
This also affects installation trust. If the website is unavailable, a user should not hunt random mirror links. The safer public surface is the GitHub release page, where assets, signatures and the release timeline are attached to the project repository. That does not make every release automatically safe, but it gives the user a coherent chain: repository owner, tag, assets, updater manifest and code history.
For Crays readers, the lesson is simple: Lume belongs in the apps shelf because it is a genuine Nostr client, but the page should not talk as if a polished marketing site is the source of truth. It should talk from what is still verifiable: releases, code, dependencies, open issues and the current reboot. That makes the article more useful than a directory blurb that simply says `desktop client`.
A Tauri app before the reboot
The v24 generation is a Tauri 2 application with a React front end. Its `package.json` lists React 19 release-candidate packages, TanStack Router, TanStack Query, Tauri plugins for clipboard, dialog, file system, HTTP, OS, process, shell, updater, upload and window state, plus Radix UI components, Tailwind and virtua for virtualized lists. It also includes `@getalby/bitcoin-connect-react`, `nostr-tools`, `light-bolt11-decoder` and Bitcoin unit formatting libraries.
The Rust side uses Tauri 2, nostr-sdk with LMDB, WebLN and all-NIPs features, nostr-connect, keyring storage, notifications, updater support, a store plugin and platform-specific desktop behavior. The Tauri config enables tray icon behavior, asset protocol access over application and user directories, updater endpoints, Windows quiet install behavior and macOS support back to 10.15. This is a real desktop stack with OS integration, not a browser tab wrapped in a thin frame.
That stack explains both Lume's appeal and its risks. It can store local Nostr data, talk to relays, run background tasks, show native notifications, update itself, access selected files and coordinate with local key storage. Those capabilities are exactly what a desktop Nostr client needs. They are also why users should treat it like sensitive software. A desktop client can sign events, cache social data, hold a wallet connection and watch local files for uploads.
Accounts, watch mode and signer choices
Lume's v24 account flow exposes three different entry points. A user can import a private key beginning with `nsec`, import an encrypted `ncryptsec` with a password, connect through a `bunker://` Nostr Connect URI, or use watch mode with an `npub` or `nprofile`. That range is meaningful because it gives users a way to read with a public key, sign locally with a private key, or delegate signing through a remote signer.
The Tauri account code stores imported account material through the operating-system keyring under `Lume Safe Storage`. The app also has Nostr Connect handling that opens an auth URL in the user's browser and stores signer state through the Nostr client. The current Rust/GPUI reboot keeps this theme but simplifies the surface: onboarding offers Nostr Connect through QR, includes nsec.app, Amber and Aegis as signer app examples, and login accepts `nsec`, `ncryptsec` or `bunker://`.
That makes Lume more security-aware than a client that only asks users to paste an nsec. It still requires careful use. Importing a raw private key into any desktop app expands the device's trust boundary. Watch mode is safer for exploration. Nostr Connect is safer when the remote signer gives clear approvals and revocation. The right first test is not `Can it load my main identity?` It is `Which account mode lets me evaluate Lume without risking the key that already matters?`
Relays, local storage and sync
Lume's v24 code starts a nostr-sdk client with an LMDB database, gossip enabled, latency and timeout options, bootstrap relays and a discovery relay. The visible bootstrap list includes `relay.damus.io`, `relay.primal.net`, `nostr.fmt.wiz.biz`, `directory.yabu.me` and `purplepag.es`, with `user.kindpag.es` added as a discovery relay. The app can connect and remove relays, ask for all connected relays, fetch relay lists and display relay viewer columns.
The app is also local-first in a practical sense. Event commands often query the local database before asking relays. Notes, profiles, contact lists and relay lists are stored and reused. Metadata requests are queued and batched. The v24 main process runs background loops for notifications and periodic sync. Sync filters include text notes, reposts, follow sets, contact lists, mute lists, profile metadata, interest sets, comments and deletion events.
Negentropy appears in release notes and sync code as a way to make desktop catch-up less clumsy. A desktop client is often opened after hours or days away; it needs to reconcile local state with relays without refetching the world every time. Lume's exact implementation may change with the reboot, but the design concern is right: local databases and sync strategy are not extras. They decide whether a Nostr desktop client feels fast or stale.
Columns are the product idea
Lume's distinctive interface idea is columns. The v24 resources define default onboarding and launchpad columns, plus optional search, global feeds and trending columns. The route tree adds columns for newsfeeds, relay feeds, interests, users, events, groups, notifications, replies, search, stories, DVM results and launchpad discovery. That is closer to a desktop control surface than a single mobile feed.
The launchpad code is revealing. It gathers newsfeeds, relay feeds, interests, content discovery and core actions into one place. Release notes mention discover newsfeed columns from NIP-51 follow sets and discover interest columns from NIP-51 interest sets. A user can build different reading contexts instead of living inside one chronological firehose. That matters for Nostr because one global feed is often the worst way to understand a relay-fragmented social graph.
This is where Lume earns its place as a separate article. Many Nostr clients can show notes, replies and profiles. Lume's desktop promise is that users can assemble views: a local feed, a relay feed, a specific user's feed, a follow set, an interest set, a search column, notifications, DVM output or a thread. If that design is revived cleanly in the reboot, Lume could be useful precisely because it does not try to feel like a phone app on a large screen.
Publishing, comments and deletion
The v24 event code signs and publishes text notes, replies, reposts and deletion requests. New notes are built with tags extracted from content, a `client` tag set to Lume, an optional content-warning tag and optional proof-of-work difficulty. Replies use Nostr's comment builder, which maps to the newer NIP-22 comment model rather than only older thread tags. Reposts use the nostr-sdk repost call, and deletion requests use the event deletion path.
The code also supports event lookup, local event lookup, hashtag queries, author queries, search filters and conversion to Bech32 event or profile identifiers. It can ask the local database which relays have seen an event and include relay hints in a NIP-19 profile or event reference. These are small behaviors, but they matter because Nostr links are more useful when they carry enough context for other clients to find the same event.
The caution is that deletion on Nostr remains a request, not a universal undo. Lume can publish a deletion event and detect whether the local database has a matching deletion event. Relays and other clients still decide what they retain and show. A desktop client can make deletion visible and convenient, but it cannot promise that every relay, cache or screenshot will disappear. Readers should treat Lume's deletion support as protocol participation, not platform erasure.
Zaps and wallet connection
Lume's v24 generation includes zaps as a first-class social action. The React note button opens a zap window when the setting is enabled. The Rust command layer can store a Nostr Wallet Connect URI, load it from OS keyring storage, remove it, set a nostr-sdk zapper, zap a profile, and zap an event with an optional message. The front end also uses Bitcoin Connect, which fits the flow of connecting a Nostr app to a wallet without making the client itself a wallet.
That makes Lume an app with wallet connectivity, not a wallet article. The reader is still using an external wallet path. The NWC URI is powerful because it can authorize payment behavior depending on the wallet's limits and approval model. Lume stores that URI under a `Bitcoin Connect` keyring entry and then asks the nostr-sdk client to use it for zaps. That is convenient, but it should be tested with small amounts and revocable permissions.
The zap design also shows why desktop clients are different. A user may leave Lume open all day, receive notifications, browse multiple feeds and zap from context. That is great when the wallet connection is bounded. It is risky if a spend-capable URI is copied into a desktop environment with weak device security, no wallet limits or unclear revocation. A good Lume setup starts with a limited wallet connection, not the largest balance a user controls.
Media, search and DVM discovery
Lume's v24 front end includes media selection and upload code. The utility function accepts common image, audio and video extensions, reads a selected local file through Tauri file APIs, uploads it to `nostr.build`, and returns the URL from the response. That is a pragmatic choice. Nostr events usually carry media URLs, not large media bytes. The client needs an upload path if it wants desktop users to post images, clips or audio from local storage.
Search and discovery are also part of the app. The command layer supports Nostr search filters, hashtag feeds, relay-specific feeds, global local feeds and custom event-kind queries. It also asks for DVM providers advertising kind 5300 jobs and can request events from a provider. In the user interface, launchpad and columns expose this as a more organized way to find feeds, interests and content.
The limitation is the same as in other Nostr clients: external services shape the experience. Search depends on relay and database coverage. Media depends on upload services and hosting durability. DVM results depend on providers, job formats and relay delivery. Lume's code is valuable because it exposes these layers instead of pretending one client controls them all. A reader should test each layer separately before relying on it for daily use.
The Rust GPUI reboot
The current master branch is no longer the Tauri app described in the v24 README. It is a Rust workspace with crates for the app shell, assets, account state, note registry, person registry and shared state. It depends on GPUI and GPUI components, rust-nostr's nostr-sdk, nostr-connect, nostr-lmdb and nostr-gossip-memory. The README is intentionally short and says the project is rebooting.
The new code is still recognizably Lume. Constants keep the client name, an application ID, bootstrap relays and a default Nostr Connect relay at `wss://relay.nsec.app`. The account crate subscribes to profile metadata, contact lists and other metadata after a public key is set. The note registry listens to nostr notifications and stores text notes and reposts. The person registry keeps profile entities updated from metadata events. The state crate builds a global nostr client with LMDB and in-memory gossip.
The reboot also changes the reader's expectations. The old app is installable through releases; the new branch is a work in progress. If a reader wants a working desktop client today, they should inspect the latest release assets and open issues. If a reader wants to understand where Lume is heading, the GPUI branch is more interesting. It suggests a leaner native Rust desktop app with local storage and Nostr Connect at the center.
Known rough edges
Open GitHub issues give a more useful picture than promotional copy. In 2024 and 2025, users reported Windows crashes, slow performance compared with older 3.0 builds, profile navigation problems, horizontal scrolling problems, autorefresh requests and Nostr Connect trouble with an nsec.app bunker. Release notes also show a steady stream of fixes for startup crashes, macOS behavior, notification columns, dark-mode visibility and multi-account feeds.
Those reports should not be read as a verdict that Lume is bad. They are the normal scars of a desktop client that touches many hard surfaces: Tauri windows, Rust background tasks, webviews, OS notifications, keyring APIs, remote signers, relay timing, local databases, virtualized lists and app updates. A simple web client can avoid some of those problems. A desktop client cannot.
The practical conclusion is caution with primary identity and expectations. Lume is worth testing if the reader wants a desktop Nostr workspace, but it should be tested with a disposable or watch-only account first. Check whether the release opens on the target operating system, whether sync completes, whether Nostr Connect works with the chosen signer, whether zaps are disabled or limited until configured safely, and whether relay columns actually load useful data.
Who should try Lume
Lume is most interesting for users who want Nostr to feel like desktop software: columns, persistent windows, local data, background sync, notifications, signer choices and keyboard-time reading. It is less compelling for someone who only wants a polished mobile timeline. Its strongest idea is not one feature. It is the assumption that Nostr can be a workstation surface where feeds, relays, people, interests and wallet actions sit side by side.
Developers should open Lume for a different reason. The v24 tag shows a full Tauri Nostr client with generated command bindings, Rust commands, keyring storage, nostr-sdk, Bitcoin Connect, NWC zaps, LMDB, media uploads and release packaging. The master branch shows a possible Rust-native future with GPUI and rust-nostr crates. That makes Lume a useful case study in how much infrastructure a desktop Nostr client actually needs.
Normal users should start gently. Download only from the official GitHub release path, verify the release they are using, begin with watch mode or a test account, keep wallet permissions low, and pay attention to open issues. If Lume becomes your preferred desktop window into Nostr, it should earn that trust through a week of real use: startup, sync, relays, profile loading, posting, replies, zaps, notifications and key handling all working in the environment you actually use.
Sources worth opening
Useful sources are the v24.11.8 README and release assets, the current GitHub repository, Tauri configuration, Rust and TypeScript command files, release notes, open issues, and the NIPs behind Lume's signer, relay, feed, zap and deletion behavior.
- Lume GitHub repository
- Lume current README
- Lume v24.11.8 release
- Lume releases list
- Lume v24.11.8 README
- Lume v24.11.8 package.json
- Lume v24.11.8 Tauri Cargo manifest
- Lume v24.11.8 Tauri configuration
- Lume v24.11.8 default relays
- Lume v24.11.8 default columns
- Lume v24.11.8 account commands
- Lume v24.11.8 event commands
- Lume v24.11.8 metadata and wallet commands
- Lume v24.11.8 relay commands
- Lume v24.11.8 sync command
- Lume v24.11.8 main process
- Lume v24.11.8 Nostr Connect route
- Lume v24.11.8 secret-key import route
- Lume v24.11.8 watch-mode route
- Lume v24.11.8 launchpad column
- Lume v24.11.8 note zap button
- Lume v24.11.8 utilities and media upload
- Lume v24.11.8 developing guide
- Lume v24.11.8 icon asset
- Lume current Cargo workspace
- Lume current app Cargo manifest
- Lume current constants
- Lume current state crate
- Lume current account crate
- Lume current note registry
- Lume current person registry
- Lume current onboarding panel
- Lume current login panel
- Lume current feed panel
- Lume open issues
- Issue 239: nsec.app bunker connection error
- lumehq/nostr-connect repository
- rust-nostr repository
- Tauri documentation
- GPUI repository
- Nostr NIPs repository
- NIP-05 DNS-based identifiers
- NIP-09 event deletion
- NIP-13 proof of work
- NIP-19 Bech32 encoded entities
- NIP-22 comments
- NIP-46 Nostr remote signing
- NIP-47 Nostr Wallet Connect
- NIP-50 search capability
- NIP-51 lists
- NIP-57 Lightning zaps
- NIP-65 relay list metadata
- NIP-77 Negentropy syncing
- NIP-90 data vending machines
- nostr.build upload service
- Alby Bitcoin Connect
