CraysAlby Go
Alby Go takes the self-custodial wallet service behind Alby Hub and makes it usable from a phone. It is small on purpose: connect a wallet, send, receive, switch wallets, save contacts and carry your Lightning payment interface away from the desktop.
The phone is a different wallet surface
Alby Go exists because a browser extension is not enough. Lightning payments happen at counters, meetups, conferences, restaurants, vending machines, gift-card sites, peer-to-peer splits and QR-code moments. A desktop browser signer may be perfect for web zaps, but it feels wrong when you are standing in front of a merchant or scanning an invoice from a phone. Alby Go moves the Alby wallet experience into the place where many payments actually happen: the mobile screen in your hand.
The public Alby Go page describes the product as an easy mobile Bitcoin wallet that connects your Hub and lets you spend from your node, manage multiple wallets, use contacts, discover merchants through BTC Map and confirm new app connections to Alby Hub from the phone. The Alby guide describes it as a simple Lightning mobile wallet interface that works with Alby Hub or any other NWC wallet service. The GitHub README uses nearly the same definition. This consistency is useful: Alby Go is a mobile interface for a connected wallet service, not a standalone node.
That distinction determines the route. Alby Go belongs under Wallets because the reader's main question is how money moves, which wallet is connected and what permissions exist. It also belongs on the Apps hub because many readers find it while comparing Nostr and Lightning tools. The Apps shelf can link to it, but the article should teach the wallet model.
What Alby Go actually controls
Alby Go controls a connected wallet through NWC. The guide says the user connects a Lightning-enabled node or wallet using a Nostr Wallet Connect secret, either by scanning a QR code or pasting an NWC connection string. Once connected, the app becomes a mobile interface for sending and receiving payments through that wallet. The money is not magically inside the phone app just because the phone shows a balance. The app is talking to a wallet service.
That wallet service is often Alby Hub, but the docs explicitly point to any NWC-powered Lightning node or wallet service. This is the most important sentence in the product description. Alby Go is not only a companion app for one hosted service. It is part of the NWC interface category: mobile wallet front ends that can operate against a remote wallet service. The phone becomes a controller, and the wallet service remains the engine.
For users, this means setup should begin with a simple question: which wallet am I connecting? If the answer is Alby Hub in the cloud, your availability and backup assumptions are different from a self-hosted Hub, Umbrel, Start9 or another NWC service. If you connect several wallets, the app's wallet switcher becomes a safety feature. You need to know which wallet is active before you pay.
NWC makes the mobile pattern possible
Nostr Wallet Connect is what lets Alby Go stay lightweight. NIP-47 defines encrypted request and response events between a client and a wallet service over Nostr relays. A client can ask the wallet service to pay an invoice, create an invoice, report balance, list transactions or send notifications depending on supported methods. The connection URI includes relay information and a secret that gives the client its own connection identity.
In practical terms, Alby Go does not need to embed every node implementation. It needs to understand the NWC relationship and present it cleanly. The user scans or pastes the connection secret, names the wallet, and uses send or receive. Under the hood, the app and wallet service communicate through the NWC path. That is why NWC is not just a developer acronym here; it is the reason a mobile app can control a wallet service that may be running somewhere else.
The security implication is direct. An NWC secret is not a public profile link. It is a capability. If it grants payment authority, leaking it can be serious. If it has tight permissions and budgets, the damage is smaller. If it is broad and not revocable, the damage is larger. Alby Go's simplicity should not make the connection secret feel casual. Treat it like a key to a specific wallet relationship.
Send, receive and the two-button discipline
Alby's guide deliberately frames the app around send and receive. To send, the user can scan a Lightning invoice QR code, paste an invoice, manually enter a Lightning address or select a saved contact. To receive, the user can show a QR code, share a Lightning address, choose an amount to generate an invoice, or redeem an LNURL withdraw QR code. That is not a feature explosion. It is a compact mobile payment grammar.
The two-button discipline matters because mobile wallet interfaces are easily overstuffed. A phone wallet should make the most common actions obvious and push advanced configuration into wallet setup or Hub management. Alby Go is not trying to be a full node dashboard. It is trying to answer the live question: how do I pay or get paid right now with the wallet I connected?
The tradeoff is that some advanced wallet state is elsewhere. Channel management, deeper Hub configuration, app marketplace settings, backups and infrastructure decisions belong in Alby Hub or the relevant wallet service. Alby Go should not be judged for not being every interface. It should be judged for whether it makes the live mobile action clear and whether it tells the user enough about the wallet behind that action.
Contacts, Lightning addresses and social money
The contact list is more important than it sounds. Lightning invoices are disposable and ugly. Lightning addresses are human-readable and reusable. A mobile wallet with a contact book turns repeated payments into a social object: friends, merchants, creators, event staff, service providers and regular recipients. Alby Go's own page highlights adding Lightning addresses to contacts and paying instantly.
This is where the Nostr connection becomes practical even if Alby Go is not a Nostr social client. Nostr profiles often carry zap endpoints and Lightning addresses. People who discover each other through Nostr may still want to pay through a mobile wallet. If the app can store a contact and remember an address, the social graph and payment graph start to meet in the user's habits. That is not automatic protocol integration; it is product continuity.
There is also a safety side. Contacts reduce typo risk and repeated manual entry, but they can preserve stale or wrong addresses. Users should verify important contacts, especially for larger payments or public merchant addresses. A Lightning address is easier to read than a BOLT11 invoice, but it is still a payment target. Convenience should make verification easier, not optional.
BTC Map and real-world spending
Alby Go's product page highlights BTC Map discovery, and the guide lists BTC Map as an additional feature. That is a clear signal about intended use. This is not only a wallet for sending zaps inside social apps. It is also meant for finding places that accept Bitcoin and paying in person. BTC Map gives a user local context; Alby Go gives them the mobile payment surface.
Real-world payments are where mobile UX becomes unforgiving. The user may have weak connectivity, a merchant may show a QR code under bad lighting, the invoice may expire, the wallet service may need to be online, and the user may be nervous because someone is waiting. A mobile app has to compress a lot of complexity into a few clear screens. The Google Play listing's emphasis on paying for drinks, gift cards, streaming services, zaps and splitting bills shows this everyday-payment ambition.
For Crays, that matters because venue and community use cases are central to Nostr's social value. A Nostr profile and a Lightning address are nice online. A mobile wallet that lets someone pay at a meetup, conference, cafe or event is what turns the protocol conversation into daily behavior. Alby Go is therefore not just a companion app; it is part of the bridge from web identity to physical payment moments.
Confirming app connections from the phone
One of the most interesting claims on the Alby Go page is that the app can confirm new app connections to Alby Hub from the phone. This is a small sentence with a large product implication. If the user can authorize new connections without opening the Hub interface directly, Alby Go becomes a mobile control point for the wider app ecosystem around the wallet.
That can make onboarding much faster. Imagine a user trying a new Nostr app, point-of-sale tool or media service that needs a wallet connection. Instead of going back to a desktop Hub dashboard, the user can approve from a phone. This is exactly the kind of workflow NWC was meant to enable: wallet services stay connected, apps request scoped capabilities, and users authorize without moving raw node credentials around.
It also means the phone becomes a high-value approval device. If Alby Go can approve new app connections, phone security matters. Screen locks, device compromise, notification privacy and stolen phones are part of wallet security. The app may be simple, but the device is not a toy. A user should treat approval prompts on mobile with the same care as browser prompts in Alby Extension.
Open source, app stores and release reality
Alby Go is open-source on GitHub. The repository shows an Expo and React Native style mobile app with hundreds of commits, iOS and Android development notes, notification code and a Zapstore configuration file. That open repository is a valuable trust signal because users and developers can inspect code, issues, release notes and build-related decisions. It also shows that mobile wallets are never just a pretty screen; they are a stack of platform permissions, notifications, app links and native behavior.
The app is also distributed through the App Store and Google Play. Those listings matter because most users will install from a store, not from GitHub. The App Store page presents Alby Go as free, in Finance, with iPhone and iPad support. The Google Play listing places it in Finance, shows 5K+ downloads, and says the developer declares no data shared with third parties, no data collected, and encrypted transit. Store claims are useful, but they should be checked against the app's privacy policy and real permissions on the device.
Release notes show a live product. Recent notes mention version 2.0.0 redesign work, a new logo and palette, a redesigned address book, BTC Map on the home screen, transaction descriptions in notifications, wallet connection information, deep-link fixes, notification polling and transaction-state alignment with Alby Hub. That is exactly what you expect from a mobile wallet tied to a fast-moving Hub and NWC ecosystem: lots of small UX and state-handling changes.
Where Alby Go can fail
Alby Go can fail at the connection layer. If the NWC connection secret is wrong, expired, revoked, scoped too narrowly, connected to a flaky relay or pointed at an offline wallet service, the app may not behave as expected. The user may see a send problem and think the mobile app is broken when the real issue is a wallet-service connection. Troubleshooting should begin by identifying which wallet is connected and whether the wallet service is reachable.
It can fail at the mobile layer. App links, camera permissions, QR rendering, notifications, deep links, background behavior and operating-system restrictions differ across iOS and Android. The release notes and issues list show this reality: receive-button bugs, notification handling, hold invoice behavior, lnurl URI support, deeplink handling and transaction states all appear as concrete work items. Mobile wallets live inside platform constraints.
It can fail at the human layer. The user can connect the wrong wallet, pay from the wrong account, save the wrong contact, expose an NWC secret, ignore a failed transaction state, or assume a merchant listing is always current. Mobile simplicity is good only if it does not erase context. A careful user checks the active wallet, amount, recipient and connection status before sending.
Privacy and data safety
The Google Play listing says Alby Go declares no data shared with third parties, no data collected and encryption in transit. That is encouraging, but it should not be read as a full privacy model by itself. Store data-safety sections are summaries supplied through platform forms. A serious user should also read Alby's privacy policy, understand their wallet backend, and remember that payments themselves can reveal timing, amount and recipient information depending on how they are made.
NWC also has metadata implications. Even if payloads are encrypted, the relay path, wallet-service availability, app connection names, notification behavior and payment timing can create observable patterns. NIP-47 is designed to avoid linking the user's main social key to wallet activity by using separate connection keys, but design intent only helps when products and users follow it. Reusing broad connections or exposing secrets weakens that benefit.
Device privacy matters too. A mobile wallet may show notifications, QR codes, recent contacts, balances, transaction history or app connection state. The user should think about lock-screen previews, screenshots, cloud backups, device sharing and app permissions. Alby Go can be part of a good privacy setup, but the phone is a very public object compared with a locked-down server.
How it relates to Alby Extension and Account
Alby Go, Alby Extension and Alby Account are often mentioned together, but they should not be collapsed. Alby Extension is the browser wallet interface and signer. Alby Account is the web account, Lightning address and service layer. Alby Go is the mobile wallet interface. Alby Hub is the wallet service. Alby Cloud is hosted Hub infrastructure. Those differences are not marketing trivia; they are the map of where trust and recovery live.
A user may use Alby Extension at the desktop, Alby Go on the phone, Alby Account for address and service settings, and Alby Hub as the wallet engine. That is a coherent setup if the user understands the boundaries. It is confusing if everything is called Alby and treated as one account. The same logo does not mean the same risk. Browser prompts, phone approvals, account login and Hub backup each need their own mental slot.
The best workflow is to test small. Connect Alby Go to the same wallet you use elsewhere, make a tiny receive invoice, send a tiny payment, save one contact, switch wallets if you have more than one, and then revoke or rename a connection so you understand the control path. Once you understand the surfaces, the stack becomes much less mysterious.
Who should use Alby Go
Alby Go is a strong fit for users who already run Alby Hub, use Alby Cloud, or have another NWC-compatible wallet service and want a clean mobile interface. It is also useful for people who pay in person, scan invoices, attend Bitcoin meetups, test NWC apps, save Lightning contacts or want to carry their Hub's payment ability away from the desktop. If your wallet life happens on a phone, Alby Go answers a real need.
It is less complete for someone who wants a full node-management interface, complex channel controls, deep accounting, or a wallet that works without any remote wallet service. It is also not a replacement for a Nostr social client or a Nostr signer. It may interact with the Nostr ecosystem through NWC and Lightning addresses, but its job is payment, not social posting.
For developers and product teams, Alby Go is evidence that NWC is not only a web-developer protocol. A mobile app can become a client to an always-on wallet service. That opens design patterns for point-of-sale, subscriptions, media apps, live events and agentic payments. But it also means app builders should explain their requested permissions clearly, because the user may approve from a small screen in a hurry.
Where it fits on Crays
On Crays, Alby Go belongs at `/nostr/wallets/apps/alby-go/` and should appear on `/nostr/apps/` as a linked product tile. This keeps discovery easy without lying about category. Readers browsing Apps can still find it. Readers studying Wallets can understand it as a mobile wallet interface and NWC client.
This also keeps the Alby product family clean. Alby Hub is the wallet service. Alby Cloud is hosted Hub. Alby Account is account and Lightning address. Alby Extension is browser interface and signer. Alby Go is mobile wallet interface. Alby Discord is community. Alby JS SDK is developer tooling. The ecosystem map becomes useful only when these pieces are separated and then linked back together.
The NWC map screenshot should not force this into a generic NIP-47 bucket. Alby Go uses NWC because it is a mobile client for wallet services. That is exactly why the article should explain NWC, but the reader needs the product story: what is installed, what connects, what is controlled, what can fail and what the user should verify before moving real money.
The practical verdict
Alby Go is the small mobile wallet interface the Alby stack needed. It makes Alby Hub and other NWC wallet services useful away from a desktop, with send, receive, contacts, wallet switching, BTC Map and mobile approval flows. Its strength is focus. It does not try to be a whole node dashboard, social client and browser signer at once.
The main caution is that focus can make the backend invisible. Before relying on Alby Go, know which wallet service is connected, how to revoke the NWC connection, what permissions or budgets apply, whether notifications are working, and what recovery path belongs to the actual wallet. The phone app is the controller, not necessarily the vault.
Used with that understanding, Alby Go is one of the clearest examples of why NWC matters. It lets a mobile app control a wallet service without moving the whole wallet into the phone. For Nostr and Lightning users, that is a practical bridge between online identity, real-world payments and self-custodial infrastructure.
Sources worth opening
Use Alby's own Alby Go page, user guides, app store listings and GitHub repository first. Then compare NWC, LNURL, BTC Map, Alby Hub and protocol sources to understand what the mobile app is actually controlling.
- Alby Go official page
- Alby Go user guide
- Alby Go guide - connect, send, receive, go
- getAlby/go repository
- getAlby/go releases
- getAlby/go issues
- getAlby/go Zapstore configuration
- Apple App Store - Alby Go
- Google Play - Alby Go
- Alby Hub user guide
- Alby official site
- Alby pricing and product comparison
- Alby Help
- Alby Feedback Forum
- Alby Terms of Service
- Alby Privacy Policy
- Nostr Wallet Connect official site
- NIP-47 - Nostr Wallet Connect
- NIP-57 - Lightning Zaps
- NIP-01 - basic Nostr protocol flow
- LNURL LUD-16 Lightning Address
- LNURL LUD-17 URL scheme prefixes
- BTC Map
- getAlby/lightning-browser-extension repository
- getAlby/js-sdk repository
