CraysbullishNWC
bullishNWC is a compact browser wallet interface for people who already have Nostr Wallet Connect strings and want one place to switch, pay, receive and test.
A browser interface for NWC strings
bullishNWC is best understood as a thin, practical control surface for Nostr Wallet Connect. It does not create a normal hosted account, run a Lightning node in the browser, hold keys for a Nostr social profile or pretend to be the wallet service behind the money. The user brings one or more NWC connection strings, gives each connection a name, and then uses the PWA to talk to those wallet services.
That makes the product small but useful. Many NWC experiments start with a string copied from Alby Hub, LNbits, a faucet, a test service or another wallet backend. A social client may use that string behind one zap button. bullishNWC turns the same kind of connection into a more general wallet screen: balance, transactions, send, receive, connection list and method display.
The app's own welcome copy describes the goal plainly: a simple, streamlined NWC wallet interface for managing multiple connections. The word wallet needs care here. The interface feels like a wallet, but the real wallet is the service reached through NIP-47. The browser app is the remote control.
The product is intentionally small
The repository is a compact static web app. There is an `index.html`, a `script.js`, a stylesheet, a manifest, a single PNG icon and a Vite build configuration. The README is only a sentence. The live app is published through GitHub Pages. There are no server routes, database migrations, user accounts or backend services in the project repository.
That smallness is part of the reader's trust model. If a person can read JavaScript, the whole application is reviewable in an afternoon. The important behavior is in one script: it imports the Alby SDK, creates NWC clients, stores connections, calls wallet methods and updates the browser UI. There is much less surface area than a full wallet company would have.
Small does not automatically mean safe. A static PWA can still store secrets in the browser, depend on remote scripts, be changed by future commits, or connect to a wallet service with wide spending rights. The benefit is inspectability. The responsibility is to inspect the actual app, the actual URL and the actual wallet permissions before using it with meaningful funds.
Its public status is easy to verify
The public GitHub repository is `thebullishbitcoiner/bullishnwc`. GitHub describes it as a JavaScript project and lists the homepage as the GitHub Pages app. The repository was created in February 2025, had one star and no forks at the time checked for this article, and was not archived. There were no GitHub releases or tags, so the clearest version marker is the PWA manifest and commit history.
The latest commit checked for this article was `v0.2.5`, dated January 30, 2026. The manifest and package file both reported version `0.2.5`. The recent commit sequence shows a short but active iteration line: payment notifications, modals, localStorage prefixing, test wallet creation, send and receive modals, edit and delete connection actions, transaction detail metadata, and the decision to remove the service worker while keeping a simple manifest-based PWA.
bullishNWC also appears in the `getAlby/awesome-nwc` list under Wallet Interfaces. The merged pull request that added it described it as a simple, streamlined PWA for connecting to NWC wallets. That external listing is useful because it places bullishNWC among interface tools such as Alby Go, Brick Wallet, Vortex and Zeus rather than among wallet services that create and custody or operate balances directly.
The app icon is its own asset
bullishNWC ships its own app icon. The live page declares `bullishnwc-icon.png` as the favicon, the manifest uses the same PNG for 192 and 512 pixel icon entries, and the QR component uses that same image inside generated invoice QR codes. For Crays, that matters because the reader should see the real project identity, not a generic globe or a guessed favicon.
The source PNG in the repository is a 2048 by 2048 image. The local Crays copy is a smaller 512 by 512 derivative of that official asset so the hub card is not forced to load a multi-megabyte icon. The meaning stays the same: bullishNWC is represented by its own icon first, not by a Google favicon fallback.
This is also a good reminder for NWC tools generally. Many of them are small experiments, but their favicons and manifest icons often carry the only stable visual identity. When a project supplies that identity itself, the article should use it.
Connections live in browser storage
The central state is a browser localStorage array named `bullishnwc_connections`. Each saved entry holds a display name, the NWC URL and a flag for whether it is a test wallet. A second localStorage value named `bullishnwc_currentConnection` stores the currently selected connection URL so the app can restore it after a page reload.
That design is convenient. A user can add several wallets, switch between them from the menu, edit names or connection strings, delete old entries, and keep the current wallet across reloads. It is also exactly where the biggest local security question sits: an NWC connection URL includes a secret. Saving it in localStorage means the browser profile stores payment authority material.
For tiny test wallets, that tradeoff is often acceptable. For a real wallet connection, the user should understand the browser environment. A shared computer, synced browser profile, compromised extension, injected script or hostile local user can turn stored connection strings into a serious problem. bullishNWC makes multi-wallet use simple, but the user still has to treat the browser profile like a wallet-adjacent place.
One NWC client per selected wallet
When the user opens a saved wallet, bullishNWC constructs a new `nwc.NWCClient` with the selected `nostrWalletConnectUrl`. That is the moment where the browser interface becomes a live NWC client. The app then loads the balance, loads recent transactions, stores the current connection and tries to subscribe to payment notifications.
The code does not build its own NIP-47 cryptography by hand. It imports `@getalby/sdk@3.9.0` from `esm.sh` and uses the SDK's NWC client methods. That is a sensible choice for a small PWA because the tricky parts of Nostr Wallet Connect are delegated to a maintained JavaScript SDK. It also means the runtime supply chain matters: the app depends on remote module delivery as well as the GitHub Pages code.
Readers should separate the interface from the SDK. bullishNWC chooses what to show, what to store, which methods to call and how to handle the UI. The Alby SDK handles the NWC client mechanics underneath. Both layers matter when judging a browser wallet interface.
Balance and transactions are limited on purpose
The balance view calls `getBalance`, then converts millisatoshis to sats for display. That is the common NWC unit boundary. NIP-47 methods commonly use millisatoshi amounts, while users usually want to see sats. bullishNWC keeps the visible balance simple and does not bury the reader in unit conversions.
The transaction view calls `listTransactions` for a one-week window and a limit of 30 entries. It renders direction, amount, relative time and optional descriptions. Clicking a transaction opens a detail modal with fields such as type, state, amount, fees paid, description, description hash, payment hash, preimage, timestamps, invoice and metadata.
That transaction scope is enough for a compact wallet interface but not an accounting ledger. A user who needs full history, export, reconciliation or compliance records will want the underlying wallet service or a tool such as Clams. bullishNWC is oriented toward immediate use: what is connected, how much is visible, what just happened, and whether a payment settled.
The methods screen exposes backend reality
The connection info modal calls `getInfo` and lists the methods reported by the connected wallet service. This is more important than it looks. NWC is a protocol, but wallet services do not all expose the same set of commands. A connection may support payments and invoices but not notifications, transaction history, budgets or advanced method sets.
bullishNWC also calls `getWalletServiceInfo` and `getBudget` inside the same flow, although the visible UI mainly focuses on available methods. That tells the reader what the app is reaching for: not only balance and invoices, but service information and permission context where the backend can provide it.
A user should check this screen before expecting features to work. If the backend does not report a method, the interface cannot make it real. The useful promise of NWC is interoperability; the practical experience still depends on wallet-service support.
Sending supports invoices and Lightning Addresses
The send modal accepts either a Lightning invoice or a Lightning Address. If the pasted value starts with `ln`, bullishNWC treats it as an invoice and calls `payInvoice`. If the value contains `@`, the app asks the user for a sat amount, uses the Alby Lightning Tools `LightningAddress` helper to fetch LNURL data, requests an invoice for that amount, and then pays the resulting invoice through NWC.
That is a practical bridge between two everyday Lightning experiences. Many users think in Lightning Addresses because they resemble email addresses. NWC wallet services generally pay invoices. bullishNWC turns the address into an invoice in the browser and lets the connected wallet service handle the payment.
The boundary is worth noticing. The app does not do zap receipts, NIP-57 zap request events or social context. It pays a Lightning Address as a Lightning payment flow. That is exactly right for a wallet interface and different from a Nostr client that attaches a payment to a note, profile or live stream.
Receiving uses makeInvoice and watches settlement
The receive modal asks for a whole-sat amount and an optional description. It calls `makeInvoice` with the amount converted to millisatoshis. When the wallet service returns an invoice, bullishNWC shows it in a modal, renders it as a QR code and lets the user copy the invoice text.
The app watches for payment in more than one way. It tries to subscribe to NWC payment notifications. For a displayed invoice, it also polls `lookupInvoice` every two seconds and, if that does not work, checks `listTransactions` for an incoming transaction with the same payment hash. When it detects settlement, it hides the waiting state, refreshes balance and transactions, shows a toast and closes the invoice modal after a short delay.
This fallback approach is a good fit for the uneven state of NWC implementations. Some wallet services can push notifications cleanly. Some may support invoice lookup. Some may expose enough transaction history for a fallback check. bullishNWC does not assume a single perfect backend path.
The faucet button is for fast testing
The menu includes a Create Test Wallet button. It sends a POST request to `https://faucet.nwc.dev?balance=10000`, expects a connection URL in the response body, saves it as a new connection named Test Wallet, marks it with a Test badge and loads it immediately.
That is one of the most useful parts of bullishNWC for builders. Instead of finding a real wallet, creating permissions and funding a test balance by hand, a user can create a disposable NWC test connection and see whether the interface works. The app becomes a hands-on NWC playground rather than only a wallet for existing production connections.
The label matters. A faucet wallet is a test artifact. It should not be treated as durable savings, reliable custody or a production payment source. Its value is speed: create a connection, inspect methods, receive, pay, watch notifications, and learn how NWC behaves.
Notifications make the interface feel alive
When a wallet is loaded, bullishNWC tries to subscribe to `payment_received` and `payment_sent` notifications. On a received or sent payment, it stops invoice polling, reloads balance and transactions, and shows a toast. For received payments it also marks the visible invoice as paid and hides the invoice modal after a moment.
The code includes simple deduplication for payment toasts. It tracks the last payment hash and the last toast time so a notification and a polling response do not produce double success messages. That detail is small, but it shows the app has been used enough to encounter real event timing problems.
Notifications are also a reminder that NWC is not only request-response. A good wallet interface should react when money moves. bullishNWC does that without turning into a large dashboard.
The PWA choice is useful but modest
The manifest gives bullishNWC a standalone display mode, a black theme color, a white background, a description, a start URL and icon entries. The index page tells users how to add the app to the home screen on Android and iOS. That is enough for a phone-like experience without app-store distribution.
The recent commit history says version `0.2.0` removed the service worker and kept a simple PWA with a manifest only. That is an honest tradeoff. Without a service worker, the app does not promise a rich offline web-app model. It behaves more like a web page that can be installed to the home screen.
For wallet interfaces, that can be a virtue. Offline caching and background behavior can complicate expectations. A simple PWA is easier to reason about: open the page, connect to wallet services, use the browser session, and understand that the web origin matters.
The CDN imports deserve attention
bullishNWC imports its main runtime helpers from public CDNs: the Alby SDK, Alby Lightning Tools and Notyf through `esm.sh`, the Bitcoin QR component through `unpkg`, and Font Awesome CSS through Cloudflare. The index page also loads Notyf CSS from jsDelivr.
That is normal for a tiny static prototype and keeps the repository light. It also creates a concrete supply-chain question. The browser is not only executing code from the GitHub Pages repository. It is also executing module code fetched from CDN URLs at runtime. Some imports are pinned to versions, such as `@getalby/sdk@3.9.0`, `@getalby/lightning-tools@6.1.0`, `notyf@3` and `bitcoin-qr@1.4.1`, which is better than floating every dependency.
A cautious user can inspect the network tab, verify the exact source loaded by the current page, or self-host a reviewed copy. That may sound fussy until a NWC secret is involved. A wallet interface can be small and still deserve wallet-grade suspicion around scripts.
Custody still comes from the wallet service
bullishNWC does not decide whether the money is self-custodial. The connected wallet service decides that. A NWC string can point to a self-hosted Alby Hub, a local LNbits service, a custodial provider, a faucet wallet, or an experimental backend. The interface looks similar in each case, but the user's risk is not similar.
The user should identify who operates the wallet, what permissions the connection has, whether spending is budgeted, whether the connection can be revoked, which relay is involved, and whether the service exposes transaction history. NIP-47 gives apps a way to talk to wallets. It does not magically turn every wallet service into the user's own node.
The best way to use bullishNWC is to make each connection name meaningful. A list that says Test Wallet, Alby Hub personal, LNbits workshop or Demo faucet is safer than a list of vague labels. The app gives the user multiple connections; the user should give those connections context.
The app is strongest for builders and power users
bullishNWC is especially good for people who already know what an NWC string is. A builder can create a faucet wallet, paste a production connection, compare method lists, send a payment, create an invoice, watch whether notifications arrive and inspect transaction details. That is valuable when testing a wallet service or learning how NIP-47 behaves in practice.
It is also useful for a user who has several NWC-enabled wallets and wants a lightweight web interface without installing a mobile app. The edit and delete actions make the connection list manageable, and the current connection persistence means the app remembers the last wallet after reload.
It is weaker as a first Bitcoin wallet. A newcomer may not understand why a NWC connection string is secret, why a browser can store sensitive material, why a faucet wallet is disposable, why backend custody matters, or why available methods differ. The app is simple, but NWC itself is not a beginner abstraction unless the wallet service explains it well.
What to check before using it with real sats
First, verify the URL. The live app is served from the GitHub Pages address for `thebullishbitcoiner/bullishnwc`. A lookalike page that asks for a NWC string would be dangerous because the string carries wallet permissions. Bookmark the checked URL rather than searching for it every time.
Second, review the connection permissions at the wallet service. A low-budget, receive-only or limited-spend NWC connection is a different risk from a broad spending connection. If the wallet service lets the user revoke a connection, learn where that control lives before pasting the string into a browser app.
Third, use small balances until the full path is understood. That includes the browser profile, extensions, remote scripts, NWC relay, wallet service, spending limits and the ability to rotate or delete the connection. bullishNWC is useful because it is direct. Direct tools reward direct caution.
Where bullishNWC fits
bullishNWC fits in the thin-interface part of the NWC ecosystem. It is closer to Brick Wallet or a NWC tester than to a full wallet service. It gives the user a place to operate existing wallet connections, not a place to build a full financial identity.
That position is valuable. NWC needs wallet services, social clients, relays, SDKs, test tools and small interfaces that make the protocol tangible. A small PWA can reveal whether a wallet's NWC implementation actually feels usable. Can it show methods? Can it list recent transactions? Can it send to a Lightning Address? Can it receive and detect payment? bullishNWC answers those questions quickly.
The article-worthy point is not that bullishNWC is large. It is that it is precise. It takes the awkward object at the center of many NWC experiments, the connection string, and gives it a clean user-facing surface.
The honest read
Readers should treat bullishNWC as a focused wallet interface for NWC-aware users. It is open, small, inspectable and practical. It uses a real project favicon, a manifest, pinned browser imports, the Alby SDK, Lightning Address helpers, notification handling, invoice QR generation and the public NWC faucet.
Readers should not treat it as a custody guarantee, a hardened vault, a mobile wallet replacement for everyone or an accounting platform. The app stores NWC strings in localStorage, imports runtime modules from CDNs, and depends entirely on the connected wallet service for custody, permissions, methods and uptime.
That is not a criticism. It is the clean deal. bullishNWC is a small tool for turning NWC connections into a usable wallet screen. Use it where that is exactly what is needed.
Sources worth opening
Start with the live PWA and its GitHub repository, then read the `script.js` code paths for localStorage, NWC calls, notifications, Lightning Address payment and the faucet test wallet. Compare that with NIP-47, nwc.dev, the Awesome NWC listing and the Alby SDK packages used by the app.
- bullishNWC live PWA
- bullishNWC GitHub repository
- bullishNWC README
- bullishNWC index page
- bullishNWC main script
- bullishNWC manifest
- bullishNWC package file
- bullishNWC Vite config
- bullishNWC icon asset
- Latest bullishNWC commit v0.2.5
- bullishNWC commit history
- Awesome NWC repository
- Awesome NWC Wallet Interfaces section
- PR adding bullishNWC to Awesome NWC
- nwc.dev
- NIP-47 Nostr Wallet Connect
- NWC faucet
- Alby JavaScript SDK GitHub
- Alby SDK package
- Alby SDK version 3.9.0
- Alby Lightning Tools GitHub
- Alby Lightning Tools package
- Alby Lightning Tools version 6.1.0
- bitcoin-qr package
- bitcoin-qr version 1.4.1 CDN module
- Notyf package
- esm.sh CDN
- GitHub Pages documentation
