CraysNostr Pay
Nostr Pay is a compact Flutter client for NWC: paste a wallet connection URI, read the remote balance, create invoices and pay BOLT11 invoices from a mobile interface.
A mobile client for remote wallets
Nostr Pay is a mobile application client for Nostr Wallet Connect. Its README describes the basic job directly: connect to remote Lightning wallets through NWC. The user does not create a balance inside Nostr Pay. The balance lives in the wallet service behind the NWC connection.
That makes Nostr Pay closer to Brick Wallet, Alby Go or bullishNWC than to a Lightning node. It is a front end that sends wallet requests and renders wallet responses. The app gives the user a mobile surface for balance, receive and send actions, while the remote wallet still decides custody, permissions, limits, relays and uptime.
The most useful way to read Nostr Pay is as an early Flutter proof of a simple question: what would a minimal NWC wallet interface look like on a phone? The answer is not a large financial app. It is a connection screen, a balance screen, a receive flow, a pay-invoice flow and a small amount of wallet metadata.
The repository moved names
The project is commonly linked as `aniketambore/nostr_pay`, and that URL still resolves through GitHub. The current API response points to `anipy1/nostr_pay`. That redirect is worth noting because ecosystem lists and older articles may still use the earlier username.
GitHub describes the repository as a Dart project with the description `Nostr Pay is a mobile application client that enables users to connect to remote Lightning wallets using the Nostr Wallet Connect (NWC) protocol.` The repository was created on June 23, 2024 and had a single main commit in the shallow clone checked for this article.
The public repository is MIT licensed, not archived, and had nine stars, one fork and no open issues when checked. Those numbers should not be overread. They show a small public experiment, not a mature wallet company.
The release is explicitly early
The only public GitHub release checked for this article is `v0.1.0-debug`, published on June 24, 2024. It is marked as a pre-release and ships an `app-release.apk` asset of roughly 54 MB. The release body calls it an early debug version.
That release lists four user-facing capabilities: connect to remote Lightning wallets, view wallet balance, create invoices and pay invoices. That matches the repository code. There is no evidence in the checked repository of a polished app-store distribution, a signed production release train or a long changelog after the first public build.
A reader should treat the APK accordingly. Sideloading a debug or early Android package is different from installing a maintained Play Store wallet. If someone wants to learn from Nostr Pay, the source code is more important than the binary. If someone wants to use it with money, the first balance should be tiny.
Awesome NWC marks it as not maintained
The `getAlby/awesome-nwc` list includes Nostr Pay in the Wallet Interfaces section and describes it as a simple Android wallet connecting to a NWC wallet. The same line marks it as not maintained.
That maintenance note changes how the article should be read. Nostr Pay is still useful as a historical and technical reference. It shows a complete Flutter NWC flow using the Dart package, secure storage, BLoC state and mobile screens. It should not be presented like a current, actively supported daily wallet.
This is especially important because NWC has continued to evolve. Current NIP-47 guidance prefers NIP-44 encryption where supported, while Nostr Pay's checked code uses the Dart package's NIP-04 encrypt and decrypt path. That does not erase the project's value, but it makes maintenance status a real security and compatibility question.
The app has its own icon
Nostr Pay ships a real project logo at `assets/images/nostr_pay_logo.png`, plus web icons, Android launcher icons and iOS AppIcon assets. The large logo is a black orbit-like mark around a yellow payment card and plug shape, with a purple accent.
That logo is the right visual identity for a hub card because it comes from the project repository itself. The web favicon is only 16 by 16 pixels, while the source logo is 3464 by 3464 pixels. A scaled local copy keeps the icon sharp without loading an oversized asset.
The existence of proper app icons also confirms that Nostr Pay was more than a bare code snippet. It had a mobile UI, a brand mark, release screenshots and launcher assets, even if the public release remained early.
Flutter is the product frame
Nostr Pay is a Flutter project. The `pubspec.yaml` name is `nostr_pay`, the app version is `0.1.0`, and the Dart SDK constraint starts at 3.4.1. The dependency list is practical rather than huge: `nwc`, `flutter_bloc`, `flutter_secure_storage`, `hydrated_bloc`, `connectivity_plus`, `rxdart`, `flutter_fgbg`, `qr_flutter`, `share_plus`, `bolt11_decoder`, `auto_size_text` and `lottie` are the core pieces.
Those dependencies map cleanly to the app. BLoC and hydrated state hold the wallet UI together. Secure storage keeps the secret. Connectivity and foreground-background listeners help refresh after network or app-state changes. QR and share packages support invoice screens. BOLT11 decoding lets the pay flow validate an invoice before sending it.
The web folder exists because Flutter scaffolds web output, but the public distribution story is Android. The Android manifest names the app `Nostr Pay`, requests internet permission and uses launcher icons. The build file sets the Android application ID to `com.nwc.nostr_pay`.
Connection starts with a NWC URI
The first screen asks for a connection string with a `nostr+walletconnect://` hint. The validator rejects an empty value, rejects a URI that does not start with the NWC scheme, requires query parameters and checks that `relay=` and `secret=` are present. A Lightning Address value in the URI is optional.
That is an important user-safety detail. The app does not ask for a raw Nostr private key. It expects a wallet app connection URI created by a remote Lightning wallet such as Alby, Mutiny or another NWC-capable service. The remote service decides what that connection can do.
The connect method then parses the URI through `_nwc.nip47.parseNostrConnectUri`, derives the app public key from the secret, stores the secret and puts the wallet pubkey, app pubkey, relay and optional Lightning Address into state.
The secret is stored separately
Nostr Pay uses a `NWCCredentialsManager` and a small `KeyChain` wrapper around `flutter_secure_storage`. The key name is `account_secret`, and the app stores only the parsed NWC secret through that path.
The BLoC state is hydrated separately. The serialized state includes type, balance, max allowed to pay, wallet pubkey, app pubkey, relay, optional Lightning Address and connection status. It does not include the secret in the JSON state object.
That split is good architecture for a mobile wallet interface. It does not make the app a vault, and it does not make a broad NWC connection low-risk. But it is materially better than putting the NWC secret in plain hydrated state or a normal preferences object.
The protocol flow is easy to see
`NWCAccountCubit` is the core file. It creates an `NWC` instance in `main.dart`, initializes the relay service with the relay from the connection URI, subscribes to events from the wallet service and reacts to result types. The subscription filter listens for kind 23195 events authored by the wallet pubkey.
When a response event arrives, the app decrypts the event content with `_nwc.nip04.decrypt`, parses the result through `_nwc.nip47.parseResponseResult`, and then branches on `get_balance`, `make_invoice`, `pay_invoice`, `lookup_invoice` or error.
When the app wants to ask the wallet for something, `_sentToRelay` encrypts a JSON message with `_nwc.nip04.encrypt`, creates a kind 23194 event tagged to the wallet service pubkey and sends it to the relay. That is NIP-47 in a readable Flutter shape.
The NIP-04 detail matters
The checked Nostr Pay code uses `nip04` helpers for request and response encryption. That matched earlier NWC implementations, and the `nwc` Dart package page also discusses NIP-04. Current NIP-47 text, however, describes NIP-44 as the preferred encryption mode and treats NIP-04 as legacy compatibility.
This is not a reason to dismiss the app as useless. It is a reason to be precise. Nostr Pay is a 2024 early client. It can teach the shape of NWC, but a modern production client should check encryption negotiation, wallet-service info events and current NIP-47 requirements.
For a reader, the practical question is simple: will the wallet service they want to use still support the encryption path the app uses? If the backend has moved to NIP-44-only behavior, an old NIP-04 client may not work. If it does work, the user still needs to decide whether legacy encryption is acceptable for the funds involved.
Balance is read as millisats, shown as sats
The app refreshes by sending a `get_balance` request. When a balance response arrives, `assembleNWCAccountState` converts the returned balance and max amount from millisatoshis into sats with integer division by 1000.
The home screen displays that balance as formatted sats. The wallet details dialog shows balance, relay, maximum allowed to pay, wallet pubkey and optional Lightning Address. That is a useful surface because NWC connections can carry limits and identity clues that should not be hidden from the user.
The screen does not show a full accounting history. Nostr Pay's checked code is about current balance and immediate payment actions. Users who need transaction history, export or reconciliation need another interface or the underlying wallet service.
Receive creates a BOLT11 invoice
The receive screen asks the user for a sat amount and an optional description. It validates that the amount is present and positive, limits the description to 90 characters, and calls `makeInvoice` on the account cubit.
The account cubit sends a `make_invoice` request with the amount multiplied by 1000 so the wallet service receives millisatoshis. If no description is provided, the default description is `Nostr Pay`.
When the `make_invoice` response arrives, the app opens an invoice QR page. That page displays a QR code, offers Copy Invoice and Share Invoice buttons, shares a `lightning:` URI and starts polling `lookup_invoice` every two seconds to notice settlement.
Send is intentionally narrow
The send page asks the user to paste a BOLT11 invoice. It decodes the invoice with `bolt11_decoder`, rejects empty input, rejects invalid invoice text and rejects zero-sat invoices. If the invoice is valid, it opens a confirmation dialog before payment.
The actual payment request is small: method `pay_invoice` with the invoice in params. When the response arrives with result type `pay_invoice`, the payment result handler shows a success page.
This is a narrower send flow than Brick Wallet. Nostr Pay does not expose LNURL pay, LNURL withdraw, Lightning Address translation or QR scanning in the checked source. The value of the app is the clean BOLT11/NWC path, not broad Lightning UX coverage.
Settlement feedback is split by direction
Outgoing payments are handled through a payment result stream. When the cubit sees a `pay_invoice` result, it pushes a `NWCPaymentResult` into a stream, and `PaymentResultHandler` opens a success page with the title `Payment Successful!`.
Incoming invoice settlement is handled on the invoice QR page. The page polls `lookup_invoice`; when the lookup result has a settlement timestamp, it navigates back toward the home route and opens a success page saying the payment was received successfully.
That split is easy to understand as a mobile app pattern. Send confirmation and receive confirmation have different screens and different timing. The shared backend mechanism is still NWC response events.
Connectivity and foreground refresh are modest
Nostr Pay tries to reconnect or refresh in a few simple ways. If initialization leaves the connection disconnected, it watches connectivity changes. Once connected, it refreshes balance and listens for foreground events; if the app has been away for more than the configured sync interval, it syncs again.
That is helpful for a mobile interface, but it should not be mistaken for a full wallet daemon. The app is not maintaining channels, routing payments or indexing all wallet activity in the background. It is refreshing a NWC connection enough to keep a small UI useful.
The design is honest for a first version. The balance and payment actions should update when the user returns to the app, and error responses can become toasts. Anything more advanced belongs in later maintenance work.
The Android build is not a polished store build
The Android manifest requests internet access and defines a normal launcher activity. The Gradle file sets the app ID and minimum SDK, but the release build type uses the debug signing config. There is also a TODO comment about adding a real signing config for release builds.
That matches the public release label. The artifact is an early debug APK, not a store-vetted production wallet. A user who sideloads it should understand Android unknown-source installation risk and should not paste a high-authority wallet connection into an unreviewed build.
For developers, the build state is more useful than troubling. It shows exactly where the app would need work before being presented as a production wallet: signing, release pipeline, current NIP-47 encryption, testing, permission language, distribution and long-term maintenance.
The tutorial gives useful author context
Aniket Ambore published a DEV tutorial on building a Nostr Wallet Connect mobile app with Flutter and the `nwc` Dart package on June 23, 2024, the same day as the repository's initial commit. The article walks through the same architectural pieces visible in the repository: NWC initialization, connection URI parsing, relay subscription, event decryption, balance handling, invoice creation and payment.
That tutorial matters because it frames Nostr Pay as both an app and a teaching project. It is not only a wallet binary dropped without explanation. It is a concrete example for Flutter developers who want to understand how a NWC client can be assembled.
For readers who build, the tutorial and repository should be read together. The article explains the intended shape; the source shows what actually landed in the app.
What users should check first
First, check maintenance status. The public ecosystem list marks Nostr Pay as not maintained, the latest checked release is from June 2024, and the release is a debug pre-release. That is enough reason to avoid using it as a primary wallet interface.
Second, check the permissions of the NWC connection. A connection that can pay invoices with a high limit is a hot payment credential. If the wallet service supports spending caps or revocation, configure those before testing.
Third, check compatibility with the wallet service. Because the checked code uses NIP-04 helpers, a backend that expects current NIP-44 negotiation may behave differently. Test with a disposable wallet connection before trusting the app with meaningful funds.
What developers can still learn
Nostr Pay remains valuable for builders because the code is small enough to follow. It shows how to parse a NWC URI, keep the secret out of hydrated state, derive the app pubkey, initialize a relay, subscribe to response events, decode NIP-47 results and send wallet commands.
It also shows a mobile product shape. The app has a proper onboarding screen, balance card, wallet details dialog, receive screen, invoice QR screen, pay-invoice screen, payment confirmation dialog and success pages. That is more concrete than a protocol snippet.
A modern fork would need updates, but it would not start from zero. The app already sketches the useful parts: secure secret storage, BLoC state, NWC methods, invoice screens and user confirmation.
The honest read
Nostr Pay is best understood as a 2024 Flutter NWC client and teaching artifact. It makes the remote-wallet idea tangible on Android: paste a connection URI, see a balance, receive a BOLT11 invoice and pay a BOLT11 invoice.
It should not be treated as a current hardened wallet. The public build is a debug pre-release, Awesome NWC marks it as not maintained, the Android release uses debug signing config in the checked project, and the NWC encryption path reflects an earlier NIP-47 era.
Used carefully, Nostr Pay is still worth documenting. It captures an important moment in the NWC ecosystem: developers were proving that a small mobile app could operate a Lightning wallet through Nostr without becoming the wallet itself.
Sources worth opening
Start with the GitHub repository, README, release page and `pubspec.yaml`, then inspect `NWCAccountCubit`, the secure-storage wrapper, the connect screen, invoice screens, Android manifest and release metadata. Compare those files with NIP-47, the Dart `nwc` package, nwc.dev and the Awesome NWC maintenance note.
- Nostr Pay GitHub repository
- Legacy Nostr Pay repository URL
- Nostr Pay README
- Nostr Pay pubspec
- Nostr Pay lockfile
- Nostr Pay v0.1.0 debug release
- Nostr Pay APK asset
- Nostr Pay main app entry
- Nostr Pay NWC account cubit
- Nostr Pay account state
- Nostr Pay credentials manager
- Nostr Pay secure-storage wrapper
- Nostr Pay connect screen
- Nostr Pay home screen
- Nostr Pay wallet details dialog
- Nostr Pay create invoice screen
- Nostr Pay invoice QR screen
- Nostr Pay pay invoice screen
- Nostr Pay payment result handler
- Nostr Pay Android manifest
- Nostr Pay Android build file
- Nostr Pay logo asset
- Nostr Pay web manifest
- Nostr Pay DEV tutorial
- Awesome NWC repository
- Awesome NWC Wallet Interfaces section
- Bitcoin Review Nostr Projects entry
- nwc.dev
- NIP-47 Nostr Wallet Connect
- NIP-47 source on GitHub
- NIP-04 encrypted direct message
- NIP-44 versioned encryption
- nwc Dart package
- nwc package API metadata
- nwc package repository
- flutter_secure_storage package
- Flutter secure storage API metadata
- hydrated_bloc package
- bolt11_decoder package
- qr_flutter package
- Flutter install documentation
- Dart SDK documentation
