CraysFreerse
Freerse is a mobile Nostr client that tries to make social posting, long-form writing and Bitcoin rewards live in one phone app: iOS, Android, Flutter code, relays, encrypted chats, NIP-05, zaps, NWC and media upload choices in a small but revealing project.
A social client with money close by
Freerse is a mobile Nostr client that puts ordinary social actions and Bitcoin rewards unusually close together. A user can create or import a Nostr identity, read feeds, publish notes, follow people, open profiles, send encrypted chats, write long-form posts, upload media, set a Lightning address and connect a wallet for zaps. That is a lot for a small phone app, and it explains why Freerse shows up in an NWC ecosystem map even though it is not itself a wallet brand.
The official site frames the product around social payments. It presents Freerse as a Nostr app where value can reward creativity and where Bitcoin Lightning is part of the experience rather than a separate finance tab. The App Store description is similar, though it sometimes drops one letter and writes the name as `Freese`. The app title, site, repository and Nostr profile use `Freerse`, so that is the name readers should treat as canonical.
The most important thing to understand is the distinction between payment interface and money custody. Freerse can help a user receive and send zaps, can store a Lightning address in profile metadata, and can talk to a NIP-47 compatible wallet through a `nostr+walletconnect://` connection. That does not make it a Lightning wallet in the strict sense. The wallet remains elsewhere. Freerse is the social client that asks the wallet to pay an invoice.
What can be verified publicly
The project has several public surfaces that agree on the basics. The website is `freerse.com`. The repository is `Freerse/Freerse` on GitHub. The README calls it a Nostr client for iPhone and Android and links to the official site, help center, iOS App Store, Google Play, TestFlight and the v1.5.11 APK release. The Nostr profile for the project publishes the same app links and source-code link, which helps tie the web, store and Nostr identity together.
Apple's lookup data reported version 1.5.11, a current version release date of July 9, 2024, bundle id `com.apps.freerse`, Social Networking as the primary genre, iOS 12.0 as the minimum version, and a seller URL at `freerse.com`. The App Store content advisory included unrestricted web access. That matters because Nostr clients render user-generated content, external links and media from a network that the app developer does not centrally moderate.
The public GitHub repository was created in March 2024, uses GPL-3.0 licensing, is written mostly in Dart, and had its most recent public push in August 2024 when checked on June 11, 2026. That does not prove the app is abandoned, because store builds and private work can exist outside GitHub, but it does mean a serious reader should compare the store version, the APK release and the public source code before trusting any feature list as fully current.
A Flutter app rather than a thin website
Freerse is a Flutter application, not a web page placed inside an app shell. The GitHub language data is dominated by Dart, with small amounts of Ruby, Swift, Kotlin and Objective-C around the mobile platform edges. The `pubspec.yaml` file lists Flutter, GetX, WebSocket channels, BIP-340 signing, Bech32, secure storage, SQLite, media pickers, video playback, URL launching, QR scanning, Markdown editing, Markdown rendering and Lightning invoice decoding libraries.
That dependency list fits the product. A Nostr mobile client needs WebSocket connections to relays, secp256k1 signing, Bech32 keys, local storage, media handling, link handling, profile metadata, feeds, follows and notifications. A payment-aware Nostr client also needs invoice parsing, LNURL handling, zap event construction and some way to communicate with a wallet. Freerse carries those pieces in app code rather than relying only on a browser extension.
There is one versioning detail worth noticing. The repository's `pubspec.yaml` still shows `1.5.2+3`, while Apple and the GitHub release tag point to 1.5.11. That kind of mismatch is common in small mobile projects, but it matters for auditing. A user choosing a build should look at the store listing, the release tag and the code together instead of assuming one metadata file tells the whole story.
Identity starts with a private key
Freerse follows the Nostr account model: identity begins with a keypair. The onboarding controller generates a private key, derives the public key, shows both in Nostr's Bech32 forms, stores the key material under `nostrKeys`, and writes initial profile metadata. The user is warned through the app text that the private key is the account password and cannot be recovered if lost.
The code uses `flutter_secure_storage` for the key record, which is the right direction on mobile platforms. Secure storage is still not magic. A user who screenshots an nsec, pastes it into the wrong place, backs it up unsafely, installs a malicious keyboard or uses a compromised device can still lose the account. A Nostr app can improve storage, but it cannot turn a private key into an ordinary password reset flow.
A small but important code detail is the default follow behavior. The registration controller follows three accounts after creating a new identity: a Moss account, the Freerse project account and Jack Dorsey's public Nostr key. That is not hidden monetization, but it is part of the onboarding shape. Readers who care about a neutral first graph should know that the initial follow list is not empty.
Relays are visible, editable and imperfect
Freerse connects to ordinary Nostr relays over WebSockets. The app ships with default relay lists that include widely used relays such as `relay.damus.io`, `nos.lol`, `relay.nostr.band`, `nostr.wine`, `nostr.bitcoiner.social`, `nostr.mom`, `relay.primal.net` and others. Users can add and remove relays, and the UI text explains relays as the servers that store and retrieve data for the client.
The relay service treats connected relays as both read and write relays. It starts from cached relay settings when available and falls back to default relays otherwise. It can reconnect, close relays, add a relay, remove a relay and save relay state locally. For a normal user this means Freerse is not locked to one company server. It can move with the user across a set of relay operators.
The interoperability caveat is that the public source code does not look like a full modern relay-list implementation centered on NIP-65. It uses local relay maps and older event paths around metadata, recommended relays and contacts. That does not make the app unusable. It does mean relay settings, relay discovery and outbox behavior may not match the newer expectations of clients that rely heavily on NIP-65 relay-list metadata.
Posting covers notes and long-form articles
Freerse is not only a microblogging app. The write controller chooses between ordinary note publishing and long-form publishing. Short notes are written as kind 1 events with mention and reply tags. Long-form posts are written as kind 30023 events with title and image tags. That maps Freerse directly to the part of Nostr used by long-form readers and writing clients.
This is one reason Freerse deserves its own article rather than a one-line directory entry. The App Store description talks about article subscription, and the README screenshots describe posts publishing and long article subscription publishing. The code backs that up. A user can treat Freerse as a mobile place to publish both timeline posts and longer pieces, not merely as a reader for other people's notes.
The tradeoff is polish. Long-form Nostr has many edge cases: title tags, images, Markdown rendering, mentions, `naddr` links, relay availability, edits, previews and cross-client formatting. The v1.5.11 release notes mention a long article display bug fix, which is exactly the kind of issue a reader should expect in mobile Nostr publishing. Freerse supports the shape, but serious publishing still deserves a test post before a final essay.
Encrypted chat uses the older Nostr model
Freerse advertises encrypted chat, and the source includes a `Nip04` helper that builds an ECDH shared secret over secp256k1 and encrypts content with AES-CBC before serializing it in the NIP-04 style. The message controller writes direct-message events with the recipient pubkey tag, and the app stores and restores message state locally.
That is useful, but it needs the right expectations. NIP-04 encrypted direct messages hide message content from casual relay readers, but they do not make the existence, timing or metadata of a conversation disappear. Relays can still see that encrypted events move between public keys. Devices can still leak notifications, screenshots, previews or logs. The content layer and the social graph layer are different risks.
Nostr has newer private-message work, including NIP-44 versioned encryption and NIP-17 private direct messages through gift wrap. Freerse's public chat code is built around NIP-04. That does not make it worthless. It does make it a client for everyday encrypted chat, not a high-assurance private messaging system. Sensitive conversations should use tools designed and maintained for that threat model.
Zaps are real NIP-57 work
Freerse's zap code is concrete. The `ZapService` checks profile metadata for `lud06` or `lud16`, derives an LNURL endpoint when needed, fetches the LNURL pay response, builds a NIP-57 zap request event of kind 9734, includes relay, amount, lnurl and recipient tags, adds an event tag when the zap is tied to a note, and sends the encoded zap request to the LNURL callback to receive a BOLT11 invoice.
That is the core social-payment bridge in Nostr. A post can have a public author, a public event id and a Lightning destination in the author's profile. The client turns the user's tap into a signed Nostr zap request and a Lightning invoice. If payment completes and the recipient's service publishes a zap receipt, other clients can understand that value moved in response to a social event.
The same code also reveals the normal failure modes. The recipient must have a usable Lightning address or LNURL field. The LNURL service must return a callback and invoice. The user's wallet must be connected if the app is going to pay automatically. The relevant relays must deliver the surrounding Nostr events. A zap button is simple only when the social profile, payment service, wallet and relays all line up.
Nostr Wallet Connect is a wallet control path
Freerse supports a Nostr Wallet Connect style flow through `nostr+walletconnect://` URLs. The wallet connection parser expects a pubkey in the URI host, plus `relay`, `secret` and optionally `lud16` query parameters. When configured, Freerse connects to the wallet relay and can encrypt wallet commands with the connection secret.
The pay path sends a `pay_invoice` request. Freerse encrypts the JSON command, signs an event as the wallet-connection sender, publishes it as kind 23194 with the wallet pubkey as a `p` tag, and subscribes for a response event of kind 23195. That is the right mental model for readers: Freerse is not taking custody of funds. It is asking an external NWC-compatible wallet to pay a Lightning invoice.
That separation is good, but it still creates a powerful permission. A NWC secret should be treated like payment authority, not like a harmless login token. If the URI is copied, logged, screenshotted or stored in an unsafe backup, another app or attacker may be able to use the wallet connection depending on the wallet's spending limits and approval model. Freerse's convenience makes wallet-permission hygiene more important, not less.
Media uploads rely on external services
Freerse can attach images, GIFs and video-like media from the phone. The public main-branch upload code posts multipart file data to `https://nostr.build/api/v2/upload/files`, reads the service response and extracts the returned media URL. The v1.5.11 release notes also say Freerse added Nostrcheck photo and video upload service support and a selection function for media upload services, with Nostrcheck.me and Nostr.build named explicitly.
That media model is common in Nostr clients. The event stored on relays usually contains a URL, not the full image or video bytes. The hosting service becomes an important dependency. If the service changes terms, rate limits, deletes a file, has an outage or exposes metadata, the Nostr event may still exist while the media experience degrades.
Readers should separate Nostr identity from media permanence. A Freerse note can be signed and relay-published, but the picture inside it may depend on Nostr.build, Nostrcheck or another file host. For casual posts this is fine. For archival publishing, important artwork or paid content, the user should know where media is stored, what the upload service promises, and whether they have their own backup.
NIP-05 and profile metadata are practical
Freerse includes a NIP-05 checker. The code splits an identifier into username and domain, requests `https://domain/.well-known/nostr.json?name=username`, compares the returned public key with the profile key, and stores whether the identifier is valid. The app also lets users put a Lightning address, website, picture, banner, display name and about text into profile metadata.
This is one of the places where Freerse feels like a useful phone client rather than a pure experiment. A Nostr profile is more useful when people can recognize it, verify it and pay it. NIP-05 gives a human-readable identifier. `lud16` or `lud06` gives the zap destination. Profile pictures and banners make the client readable. Freerse handles those ordinary profile tasks in the same app where the user posts.
The risk is that verification can be mistaken for identity proof. NIP-05 confirms that a domain served a public-key mapping at the time of check. It does not prove the person is who they claim to be, does not protect against domain takeover, and does not stop a domain owner from changing mappings later. It is a useful handle, not a universal trust badge.
Discovery comes from relays and Nostr Band
Freerse has search and discovery features beyond following accounts. The code includes metadata search, user search, hashtag paths and a `getHotTweets` method that requests trending notes, videos and images from `api.nostr.band`. That means the app can show more than a narrow follow feed. It can offer a broader window into what is active across parts of Nostr.
Discovery services are helpful because Nostr relays are fragmented. A new user cannot know every interesting relay, topic or account on day one. A search index or trending endpoint can make the network feel alive. Freerse's use of Nostr Band is a pragmatic solution: let a specialized index help surface notes and media while the app continues to publish and read through relays.
The tradeoff is dependency. Search results and trending views are shaped by the index service, its relay coverage, its filters and its uptime. That does not make the service bad. It means discovery is a layer on top of Nostr, not Nostr itself. A user who wants a more sovereign reading experience should learn how Freerse's relay list, follow graph and external discovery services each shape what appears on screen.
Where Freerse is strongest
Freerse is strongest as a lightweight mobile Nostr client for people who want social posting, long-form writing and zaps in one place. It is especially interesting because the Apple listing supports older iOS versions than some better-known clients, and the official site includes iOS, Android, TestFlight and direct APK paths. For readers with older devices or mixed mobile environments, that matters.
The app also helps illustrate a useful product direction for Nostr. Instead of treating payments as a separate finance product, Freerse puts zaps near social content. Instead of treating long-form writing as a different app category, it lets the write screen publish kind 30023 events. Instead of making relay choice completely invisible, it gives users relay controls and explanatory copy.
That combination makes Freerse worth tracking even if it is not the most polished or most active Nostr client. Small clients often experiment in places large clients move slowly: older-device support, multilingual interface strings, media-service choices, direct APK distribution, mobile-first long-form posting and payment features that assume value can move between readers and creators without a platform wallet in the middle.
Where readers should be careful
The first caution is maintenance visibility. The public GitHub activity visible on June 11, 2026 was older than the active codebases of several leading Nostr clients. The latest public release tag and App Store version both point to July 2024. That does not mean Freerse is unsafe, but it does mean readers should test the current app before trusting it with an important identity, large follow graph or high-value wallet permission.
The second caution is key custody. Freerse creates and stores the user's Nostr key locally. That is convenient and normal for a mobile client, but browser signers, remote signers and dedicated key-management apps exist for a reason. If a user already has a valuable Nostr identity, importing the private key into any smaller client should be a deliberate decision. A test key is often the better first move.
The third caution is payment authority. Zaps through LNURL and NWC are powerful because they make social value feel instant. They are also powerful because a wallet connection can spend money. Readers should use wallet limits, revoke unused NWC connections, avoid sharing connection URIs, and verify that the app's zap behavior matches the wallet's approval model before using meaningful balances.
How to evaluate it yourself
A sensible Freerse test begins with a throwaway or low-stakes Nostr key. Install the current store build or APK, check the version, create a profile, save the private key outside the app, add and remove a relay, post a short note, post a long-form article, upload one image, follow a test account and then confirm the events in another client. This tells you far more than a feature list.
Next, test payments with tiny amounts. Add a Lightning address to the profile if you want to receive zaps. Connect a wallet through NWC only after you understand the wallet's permission controls. Send a small zap to a known account, watch for the LNURL invoice, and check whether zap receipts and local UI state line up in another Nostr client. If something feels unclear, disconnect the wallet and inspect the wallet's NWC permissions.
Finally, test recovery. Log out only after you know where the key is stored. Reinstall on another device or import the same key into a different client. Make sure the profile, follows, relays, long-form article and zaps can be found through the broader Nostr network. A good Nostr app should feel useful inside its own interface, but the identity and content should not depend on that interface alone.
Sources worth opening
Useful primary sources are the official site, help center, App Store data, public repository, release tag, code files for relays, keys, zaps, NWC, uploads and long-form publishing, the project Nostr profile, and the NIPs behind the app's social and payment behavior.
- Freerse official site
- Freerse help center
- Freerse GitHub repository
- Freerse README
- Freerse v1.5.11 GitHub release
- Freerse Apple App Store listing
- Apple Lookup API for Freerse
- Freerse Google Play listing
- Freerse TestFlight link
- Freerse Nostr profile
- Freerse project X account
- Freerse donation link on Coinos
- Freerse pubspec.yaml
- Freerse NostrService source
- Freerse ZapService source
- Freerse wallet connection parser
- Freerse NIP-04 helper
- Freerse write-page controller
- Freerse registration key controller
- Freerse relay service
- Freerse NIP-05 checker
- Freerse default relay constants
- Freerse GPL-3.0 license file
- Freerse GitHub languages API
- Freerse GitHub tags API
- Freerse GitHub releases API
- Nostr protocol repository
- NIP-01 basic protocol flow
- NIP-02 contact lists
- NIP-04 encrypted direct messages
- NIP-05 DNS identifiers
- NIP-19 bech32 encoded entities
- NIP-23 long-form content
- NIP-42 relay authentication
- NIP-44 versioned encryption
- NIP-47 Nostr Wallet Connect
- NIP-57 Lightning zaps
- NIP-65 relay list metadata
- Nostr.build media service
- Nostrcheck media service
- Nostr Band search and discovery
- flutter_secure_storage package
- web_socket_channel package
- bolt11_decoder package
- pointycastle package
