CraysNostrmo
Nostrmo is the kind of Nostr client you open when you want one account to follow you from phone to desktop, through notes, groups, zaps, files and the messy parts of real relay life.
The client that wants to travel
Nostrmo is interesting because it does not choose the neatest lane. Many Nostr clients make a clean bargain with the user: this one is for iPhone, this one is for Android, this one is a browser client, this one is a power-user desktop app. Nostrmo tries the harder thing. It wants the same Nostr account to feel available on Android, iOS, macOS, Windows, web/PWA and Linux.
That ambition matters. Nostr is supposed to separate identity from the app, but most users still meet it through a device. If the client disappears when you move from phone to laptop, the protocol can feel portable in theory and awkward in practice. Nostrmo's public FAQ says it supports all those platforms and frames the app in plain language: a client for communicating with friends on the Nostr network. Its NostrApps entry gives the same general shape: a Nostr client for iOS, Android, macOS and Windows, with mobile, desktop and web platform badges.
The promise is not that Nostrmo is the prettiest client in every category. The promise is continuity. Follow a feed on a phone, open groups on a tablet, check relays on a computer, try the web build when you do not want to install anything. For a reader, that is the useful starting point: Nostrmo is less a jewel-box client and more a traveling workbench.
The distribution story is a little more practical than the headline. The README points to iOS, Android, macOS, Windows, web and Linux. The FAQ points iOS and macOS users to the App Store and TestFlight, Windows and Linux users to direct downloads, and web users to the PWA at web.nostrmo.com. The GitHub release page also points to ZapStore and GitHub releases for downloads. That mix tells you what kind of project this is: open-source, multi-platform, and still living partly in developer channels rather than in one perfectly tidy consumer store.
The App Store page gives the everyday-reader version of the pitch: a Nostr client built with open-source protocols, where you control the account with a Nostr key and do not need a phone number or similar account information. It lists the seller as rongzhuang yang, shows in-app "coffee" purchases as support payments, and says the developer does not collect data from the app. That privacy label is useful, but do not mistake a store label for the whole security model. With Nostr, the private key remains the thing that matters.
A big NIP surface, not a small demo
The GitHub README tells you more than the marketing line. It describes Nostrmo as "a flutter nostr client for all platforms" and then lists a large set of implemented NIPs. The checked items include the basic event flow, follows, NIP-07 browser capability, deletion, reply conventions, relay information, subject tags, reposts, bech32 entities, Nostr URI links, long-form content, reactions, text references, NIP-29 groups, custom emoji, sensitive-content labeling, relay authentication, NIP-44 encryption, Nostr Connect, Nostr Wallet Connect, search, lists, Android signer support, Lightning zaps, badges, gift wrap, relay-list metadata, zap polls, video events, moderated communities, zap goals, media attachments, file metadata, shared files, HTTP file storage and HTTP auth.
You do not need to memorize that list. What matters is the product shape behind it. Nostrmo is trying to be a full social client, not only a timeline reader. The FAQ names everyday features in the same direction: text notes, video and image notes, direct messages and private direct messages, long-form content, custom emoji, polls, zap goals, moderated communities, Lightning zaps, badges, NIP-94 file metadata and NIP-95 shared files.
That breadth has a price. A narrow client can be beautiful by refusing most of the protocol. Nostrmo is built from the opposite instinct: if Nostr has a public behavior that real users may need, the client should probably try to expose it. That makes the app useful for explorers, but it also means new users should move slowly. Start with notes, follows and relay settings. Then add groups, zaps, long-form posts and files once the account feels understood.
It is worth reading that NIP list with adult patience. Some listed NIPs are basic foundations, some are wallet or signer interfaces, some are media and community formats, and some are older or less recommended pieces of the Nostr world that remain relevant because real clients still meet old events in the wild. So the right conclusion is not "Nostrmo perfectly implements everything." The right conclusion is that Nostrmo wants to be close to the messy protocol surface instead of presenting Nostr as only a microblogging feed. That is a very different product philosophy.
This also explains why Nostrmo can feel attractive and demanding at the same time. If you are curious about NIP-29 groups, NIP-57 zaps, NIP-58 badges, NIP-69 polls, NIP-72 moderated communities, NIP-75 zap goals, NIP-94 file metadata, NIP-95 shared files and NIP-96 HTTP file storage, one client that tries to hold all of that becomes a useful lab. But if you only want a low-friction social feed, you may find the breadth heavier than you need. The app is not trying to be invisible. It is trying to carry a lot.
Keys, relays and the boring truth
The Nostrmo FAQ does something every client page should do: it talks about the private key plainly. It says login can happen by entering a private key or generating a new one, then immediately warns that the key controls the account, should not be shared, and must be backed up for recovery. That warning is not small print. It is the whole deal. In Nostr, there is no platform help desk that can politely hand your identity back after a careless paste.
The release trail shows movement on that front. In version 3.5.1, released on GitHub on March 30, 2026, the changelog says the app moved the key to secure store. That does not remove the need for careful key handling, but it is the kind of boring implementation detail that matters more than a glossy feature sentence. A client that asks for a private key has to earn trust through storage behavior, source visibility and a clear recovery story.
Relays get the same practical treatment. The FAQ tells users that if notes are not loading, relays may be overloaded and suggests adding recommended relays in relay settings, with nostr.watch as a place to look. That is the Nostr lesson in one small support answer: your feed is not one central service. It is the result of relays, subscriptions, filters, local cache and the client's patience with broken network edges.
This is where Nostrmo deserves both credit and pressure. Credit, because it exposes the basic reality: keys and relays are not background decorations. Pressure, because any cross-platform client has to solve the same problem several times. Secure storage on mobile, desktop storage on macOS and Windows, browser behavior in a PWA, local caches, notifications, media previews and signer prompts do not all fail in the same way. A good Nostrmo test is not only "Can I post?" It is "What happens to my account and cache when I move between devices, relays and builds?"
The release notes and repository also show why Android signer support, NIP-46 Nostr Connect and NIP-47 Nostr Wallet Connect matter inside this app. They are not decorative badges. They are attempts to keep signing, identity and payment flows from becoming one giant private-key paste. If Nostrmo keeps maturing, the most important improvements will likely be the least glamorous ones: safer signing, clearer relay behavior, better local storage, stronger media handling and fewer places where a user has to guess what the client is doing.
What the code trail reveals
The public repository belongs to the GitHub user haorendashu. GitHub shows Nostrmo as a GPL-3.0 project with more than 1,200 commits, a Dart-heavy codebase and platform folders for Android, iOS, Linux, macOS, web and Windows. The App Store lists the seller as rongzhuang yang, while the FAQ offers haorendashu@gmail.com for further support. That is the public trail we can verify without inventing a company story.
The project is built with Flutter, which explains the platform spread. The current pubspec.yaml lists version 3.5.1+37 and points to local packages such as nostr_sdk, flutter_nesigner_sdk, nesigner_adapter and relay_isar_db. The .gitmodules file confirms those modules as separate repositories under the same developer orbit. That matters because Nostrmo is not just one screen file and a relay call. It has a client app, SDK pieces, signer glue and a relay database layer.
The dependency list matches the app's visible ambition: cryptography packages, secure storage, cached images, media playback, QR codes, file picking, image picking, Markdown rendering, local auth, translation and language tools, desktop window management, tray support and local notifications. Even the Linux build notes reveal the kind of app Nostrmo is trying to be. It depends on system pieces like SQLite, mpv, notification libraries and app-indicator support because it is not merely a web page wrapped in a shell. It wants desktop behavior too.
The release notes give the app a lived-in texture. Version 2.9.1 moved code into the SDK package, changed nostr.build upload behavior toward NIP-96, added Web of Trust filtering and fixed group, markdown, relay and local-cache issues. Version 3.2.0 changed nesigner support and added wallet pages for wallet info, transactions, receive and send. Version 3.5.1 focused on bug fixes and optimizations: inbox support for followed and mentioned feeds, feed syncing changes, in-app webview closing, secure key storage, webapps pages, group-message fixes, image memory fixes and stricter mentioned-feed p-tag checks. This is not brochure copy. It is maintenance work.
The store and release timelines also tell a small cautionary story. The App Store shows a 3.5.1 update in late March 2026 and a small number of ratings and reviews; GitHub marks 3.5.1 as the latest release on March 30, 2026. That is a current enough trail to take seriously, but the sample of public user feedback is still small. Read it the way you would read any independent tool: the code and releases matter more than the rating average, and the rating average is not a substitute for your own account-safety test.
Why nesigner matters here
Nostrmo sits near another project from the same orbit: nesigner. The nesigner site describes an open-source Nostr hardware signer built around ESP32-S3 hardware, with JavaScript and Flutter SDKs, plus client resources that include Nostrmo, Nowser and Briner. That connection helps explain why Nostrmo's codebase includes nesigner-related packages and why release notes mention changes to nesigner support.
This is worth paying attention to because key custody is the hard part of Nostr clients. A social app can feel friendly while quietly making dangerous assumptions about private keys. A hardware-signer experiment is a different instinct: keep signing closer to a dedicated device, make integration possible through SDKs, and reduce how often the raw key has to touch a general-purpose machine. Nostrmo is not only a feed in that context. It is part of a small tool family thinking about clients, signers and cross-platform use together.
That does not mean every Nostrmo user needs an ESP32 board on the desk. It means the project trail should be read as broader than one app icon. The interesting work is the bridge between a full client, secure storage, Android signer support, NIP-46, Wallet Connect, file uploads and hardware-signing ideas. That is the kind of bridge a serious Nostr user eventually has to cross.
For a normal reader, the lesson is simple: do not judge Nostr clients only by their feed design. The feed is where you feel the app. The signer path is where you trust it. Nostrmo's connection to nesigner does not automatically make it safer than every other client, but it shows that the project is thinking about the right problem. If the private key is the account, then signing is not a side feature. It is the foundation underneath the whole social experience.
Who should try Nostrmo
Nostrmo is for the reader who wants breadth. If you only want a calm iPhone feed, Damus or Nostur may feel cleaner. If you only want an Android-native social app, Amethyst may feel deeper in the hand. If you want to see how much of Nostr can live in one cross-platform Flutter client, Nostrmo is worth opening.
The best first test is simple. Install it on one device, sign in carefully, back up the key before doing anything emotional, add or review relays, follow a few accounts and post a small note. Then check the same account from another Nostr client. If the post, profile, follows and replies behave as expected, you have a baseline. After that, test the features that make Nostrmo different: groups, long-form content, custom emoji, zaps, badges, file metadata, shared files and wallet pages.
The caution is honest: cross-platform reach is powerful, but every platform has its own storage, notification, media, signing and security edge. Nostrmo's strength is that it tries to travel. Its risk is that travel makes the surface large. Use it like a serious tool: verify the source, read the release notes, understand where your key is, and never confuse "same account everywhere" with "nothing can go wrong."
I would especially try Nostrmo if you are comparing clients for a multi-device life, if you want a Flutter reference point, if you care about NIP breadth, or if you are studying how a client touches signers, wallets and media storage at the same time. I would be more cautious if you are onboarding someone who has never held a Nostr key before. For that person, the first client should make the fewest possible demands. Nostrmo can come after the mental model is in place.
The app's rough edges are not a reason to dismiss it. They are part of its honest profile. Broad clients reveal protocol reality. They make you notice relays, old events, media paths, device storage, translation, desktop packaging and wallet flows. That is not always comfortable, but it is useful. Nostrmo is one of those apps that teaches you the network by refusing to pretend the network is smaller than it is.
Sources worth opening
These sources are the useful trail: the app directory listing, the main repository, the FAQ, the store page, the current release notes, package files, ZapStore metadata and the signer project that explains part of the surrounding technical direction.
- Nostrmo on NostrApps
- haorendashu/nostrmo source repository
- Nostrmo FAQ repository
- Nostrmo on the App Store
- Nostrmo 3.5.1 release notes
- Nostrmo pubspec.yaml
- Nostrmo Git submodules
- Nostrmo ZapStore metadata
- Nostrmo web/PWA build
- nesigner project
- 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
- NIP-19 bech32 encoded entities
- NIP-44 versioned encryption
- NIP-46 remote signing
- NIP-51 lists and mute lists
- NIP-56 reporting
- NIP-57 lightning zaps
- NIP-65 relay list metadata
