Craysfutr
futr is a native desktop Nostr client by Sascha-Oliver Prolic, built in Haskell and Qt5 with NIP-17 messaging, NIP-65 relay logic and local LMDB storage.
Software, not a tab
Most Nostr clients ask you to open a website. futr asks a slightly older, more stubborn question: what if the client is actual desktop software again? Not a web view dressed in a native window. Not a thin wrapper around the same browser assumptions. A local application, written in Haskell, drawn with Qt5/QML, shipped through Flatpak and Windows installers, with its own database and its own relay behavior.
That changes the mood of the app. When you open a web client, you usually judge it by speed, layout and whether the timeline feels alive. With futr, you also start asking where the program stores events, how it connects to relays, how it handles private messages and whether the machine in front of you is doing real work. That is the interesting promise here. futr is not trying to be the most polished first Nostr experience in the room. It is trying to be a serious native client for people who still care what runs on their own computer.
The official site introduces Futr as a gateway to a global, decentralized and censorship-resistant network. NostrApps compresses the listing into four hard clues: native OpenGL application, no browser, private encrypted chats using NIP-17, outbox model and Linux plus Windows. Those clues matter because they separate futr from the smooth web-client crowd. If you are the kind of reader who hears "native" and immediately thinks about local storage, UI bindings, release artifacts and crash behavior, this app is worth a closer look.
There is also a small naming joke in the README: the name was chosen "out of respect for the honorable Canadians." That sentence tells you something. futr is not a corporate platform with a grand manifesto. It is a builder's project with a public repo, a release pipeline and enough personality to resist becoming another anonymous purple square.
The person and the repo
The project trail points to Sascha-Oliver Prolic, the GitHub user prolic. The `futr.cabal` file names Sascha-Oliver Prolic as author and maintainer, the repository copyright line names Sascha-Oliver Prolic, and the official website footer carries the same name. His GitHub profile also publishes a Nostr npub, which is a useful detail for this ecosystem: the maintainer is not only writing code about Nostr from the outside, he is reachable in the identity space the app is built for.
The repository itself is futrnostr/futr. It is public, GPL-3.0, and as checked on June 6, 2026 it is not archived. GitHub reports the repo was created on February 1, 2022, pushed most recently on October 27, 2025, and organized around the topics Haskell, Qt5, Qt5-QML and Nostr. The visible contributor list is almost entirely prolic, with Dependabot doing dependency housekeeping. That is a different risk profile from a foundation-backed client with a large team. It can move with taste and coherence; it can also depend heavily on one maintainer's time.
The code shape is unusually readable as a product map. `app/Main.hs` boots the program. `src/Futr.hs` is the broad application layer: search, following, loading feeds, sending messages, reposts, quotes, comments and deletion. `src/Nostr/Event.hs` defines the event kinds the app understands. `src/Nostr/InboxModel.hs` handles relay subscriptions and reconciliation. `src/Store/Lmdb.hs` is the local event store. The QML files under `resources/qml` describe the interface: sidebars, feeds, post details, profile screens, relay management dialogs and image viewing.
That structure tells you futr is not a demo glued to a single relay. It is an attempt to build a client from the protocol inward: keys, events, relays, storage, presentation. Whether you like the UI is a separate question. The important thing is that the architecture has a spine.
What the screen is for
At the user level, futr is a Nostr social client. You log in with keys, read posts, search for profiles by npub, nprofile or NIP-05 identifier, follow and unfollow people, open a profile feed, write short text notes, repost, quote repost, comment and delete your own events. The code also tracks a current post and subscribes to comments around it, so the app is not merely flattening the network into a single stream.
The QML interface suggests a desktop layout rather than a phone-first feed. There is a collapsible sidebar, a personal feed, post details, an image viewer, top bar controls, key management and relay management. That matters because Nostr can become visually exhausting when every client copies the same mobile timeline into a large screen. A desktop client has room to expose state: which account is active, which relays are connected, which profile you are inspecting, whether the sidebar should collapse, whether a post has a separate detail view.
The release history gives a sense of direction. The v0.3.0 release notes, published before the current v0.5.0 release, described Windows 10 support, media support, threaded conversations, nested comment display, repost and quote handling, profile rendering, clickable profile links, improved scrolling, chat improvements, lower memory use and better relay connection handling. You should read old release notes carefully, because they are not the same as a current guarantee. But they are useful as a builder diary: futr grew from a client shell into a program that wants to handle the messy social parts of Nostr, not only sign kind-1 notes.
The media layer is worth noticing too. The repository has a `Downloader` module and application signals for download completion, media peeking and media cache completion. The UI has an image viewer. This does not make futr a media platform in the Wavlake or zap.stream sense. It means the client is trying to make ordinary social posts feel complete on the desktop, where a note with an image or video should not require three external hops before it becomes readable.
The relay brain
Nostr clients are often judged by the pretty part, but the real personality sits in relay behavior. futr's `InboxModel` module says explicitly that it follows the NIP-65 idea of relay list metadata. That is a big deal for a desktop client, because the hard question is not just "can I connect to relays?" It is "which relays should I use for this person, this post, this reply, this private message and this recovery path?"
futr stores general relays and DM relays separately. It reads relay list metadata, preferred DM relay events and follow lists. It distinguishes inbox-capable relays from outbox-capable relays. It builds a map from pubkeys to candidate outbox relays, filters out localhost relays for other people's keys, and scores relays with stored stats such as successes, errors, events seen, bytes received, last EOSE timestamp and latest event timestamp seen. In plain English: the app tries to remember which relays have been useful instead of treating every connection as a blank slate.
That is the kind of work users rarely see until it breaks. If your client cannot find someone's posts, Nostr feels broken. If replies land on relays nobody reads, the conversation feels broken. If private messages listen on the wrong relays, the social layer feels broken. futr's code shows an adult concern for that layer: connect, subscribe, wait for completion, reconcile, remove stale subscriptions, add missing relays, keep gift-wrap subscriptions alive and use timestamps so the app does not reload the whole world every time.
The default relay list includes familiar public relays such as nos.lol, nostr.bitcoiner.social and relay.nostr.bg. The app also has a relay management UI, so the model is not "trust our relay forever." The user is expected to understand that relay choice is part of the client, not a hidden backend decision.
Private messages the hard way
The private-message story is the most important technical part of futr. NostrApps advertises NIP-17 private encrypted chats. The code backs that up with event kinds for DirectMessage kind 14, PreferredDMRelays kind 10050, Seal kind 13 and GiftWrap kind 1059. That is the modern private-message route: a message is not just thrown into an old encrypted DM event and left there forever. It is wrapped, sealed and routed through the Nostr mechanisms meant to hide more metadata and make relay delivery less naive.
In `Nostr.Event`, futr creates a rumor for the direct message, seals it with encryption, and creates gift-wrap events for recipients. In `Nostr.Encryption`, the app derives a NIP-44 v2 conversation key and uses ChaCha20 with HMAC-SHA256 protection. In `Futr.hs`, when you send a private message, the app builds gift wraps for all recipients, publishes them, and notifies the feed. In `InboxModel.hs`, the client subscribes to gift wraps on DM relays and reconciles those subscriptions over time.
That is a lot of machinery for a chat bubble. It should be. Private messaging on Nostr is not magic; it is careful event construction, key agreement, relay selection and local handling. If you are evaluating futr, this is where you should slow down. Send a test message, inspect whether it appears where expected, try another NIP-17-capable client, and pay attention to relay settings. The app's code is doing the right kind of hard work, but privacy is not a slogan you accept from a landing page. It is behavior you verify.
The local store completes the picture. `Store.Lmdb` keeps events, event-relay mappings, profiles, post timelines, chat timelines, follows, general relay lists, DM relays, comments, latest timestamps and relay stats. For a desktop client, that local memory matters. It means the app can build continuity without asking one remote service to remember everything for you.
Installs and promises
The current official site points users to a Windows installer for v0.5.0 and Linux installation through a Flatpak repository. GitHub's latest stable release is `v0.5.0`, published on October 12, 2025, with a Windows setup executable and a Flatpak asset. There is also a continuous development release tagged `continuous`; as checked here, it advertises a v0.5.0.1 Windows installer and Flatpak from October 2025.
The README is more precise than the marketing page. It says Linux can be installed through Flatpak, Windows installers come from GitHub Releases, and macOS, Android and iOS are "Coming soon." The official website uses broader language about Linux, Windows, macOS, Android and iOS, but the repo and releases only make Linux and Windows concrete today. For a reader, that distinction matters. Do not assume there is a polished mobile app just because the site speaks cross-platform. Check the release artifacts first.
For developers, the project has setup documents for Linux and Windows, a Docker-based quick start, automated builds, Flatpak build scripts, Windows resource files and a Cabal project. The Cabal file lists GHC 9.6.7, secp256k1, LMDB, websockets, wuss, haskoin-core, libsecp256k1, hsqml and a long set of Haskell dependencies. This is not the easiest stack in the Nostr ecosystem. That may be part of the point. futr is built like someone wanted a durable desktop program, not the quickest possible Vite app.
The cost of that choice is practical. Smaller native clients can be harder to package, harder to debug across platforms and slower to onboard contributors into. The benefit is equally practical: you get a program that can own its storage, its windows, its relay state and its cryptographic path without delegating everything to the browser. That tradeoff is the soul of futr.
Who should try it
Try futr if you want to understand what Nostr feels like when it leaves the browser. Try it if you use Linux or Windows, like native apps, care about private-message standards, and do not mind being closer to the engineering surface than a mainstream user would be. Try it if relay management, local storage and open-source licensing are features to you, not chores.
Do not treat futr as the obvious first client for a casual friend who just wants to see what Nostr is. For that job, a polished web or mobile client may teach faster. futr is better for the reader who wants to inspect the machine while using it. The app gives you a concrete way to ask good questions: where are my events stored, which relays are read and written, what happens when I reply, how does a gift-wrapped DM travel, and can another client understand what I just did?
That is why futr belongs on the app shelf. It is not the largest Nostr client, and it is not trying to be the social network in disguise. It is a native client with a visible maintainer, GPL code, real release artifacts and enough protocol depth to be worth studying. In an ecosystem full of beautiful web clients, futr is a useful reminder that Nostr also needs strange, local, inspectable software.
Sources worth opening
Start with the project pages, then read the code paths that explain the product's real behavior.
- Official Futr website
- NostrApps futr listing
- futrnostr/futr GitHub repository
- futr README
- Release v0.5.0
- Continuous development release
- futr.cabal project file
- Developer setup guide
- Windows platform notes
- Futr application layer
- Nostr event handling
- Nostr encryption module
- Inbox and relay model
- LMDB local store
- NIP-17 private direct messages
- NIP-65 relay list metadata
- Sascha-Oliver Prolic on GitHub
- NIP-25 reactions
- NIP-27 text note references
- Nostr protocol NIPs repository
- NIP-01 basic protocol flow
- NIP-05 DNS identifiers
- NIP-07 browser signer capability
- NIP-10 text note threading
- NIP-11 relay information document
