Alby Extension

Wallets26 min readWallet interfaces

Alby Extension

Alby Extension sits in the browser, where ordinary web pages meet Lightning payments and Nostr signing. It is one of the most important UX bridges in the ecosystem, because it lets sites request payments and signatures without asking users to paste private keys or raw node credentials.

The browser was the hard place

Alby Extension matters because the browser was the place where Bitcoin, Lightning and Nostr kept colliding with normal user behavior. A website can show a button that says pay, zap, login, subscribe, tip or sign, but the user still needs a trusted interface between that page and the wallet or private key. Before browser extensions such as Alby became familiar, many web payment experiments required awkward copy-paste flows, hosted accounts, manual invoice handling or brittle integrations that felt like prototypes. The extension turned those moments into a recognizable browser action.

The extension's public descriptions are consistent across the GitHub repository, Chrome Web Store and Firefox Add-ons listing. It is a Bitcoin Lightning browser extension, a companion for Lightning and Nostr apps, a wallet interface for multiple backends, a WebLN provider, and a Nostr signer. The README emphasizes web payments rather than advanced node management. The store listings emphasize sending and receiving Bitcoin, using Lightning and Nostr apps, setting budgets, managing wallets, signing events without sharing the private key, and supporting passwordless logins.

That combination is why this article belongs under Wallets, not only Apps. Alby Extension is reached through web apps, but the important reader question is about wallet permissions, signing powers and trust boundaries. It is a browser interface that can talk to wallets and expose signing capabilities. It is a product surface where the user decides whether a website may ask for value or identity. The route should make that financial and key-handling weight visible.

What the extension actually is

At the simplest level, Alby Extension is a browser extension for Chrome-like browsers and Firefox. It lives next to the address bar, injects or exposes web-facing capabilities, and shows prompts when a site requests an action. That action might be a Lightning payment, an invoice, a message signature, an LNURL flow, a Nostr event signature or a login. The user experiences one product. Underneath, the extension may coordinate WebLN, LNURL, NIP-07, wallet backends, Alby Account, Alby Hub, NWC, local key storage and browser-extension permissions.

It should not be described as a full node manager. The README says its goal is not to provide the full channel-management interface of something like a dedicated LND node UI. It focuses on what is necessary for the web: payment and authentication flows, multiple accounts, WebLN support, LNURL support, keysend, history and metadata. That focus is the point. A browser extension should not try to become every wallet interface and node control panel at once. It should do the web boundary well.

The most useful mental model is this: Alby Extension is a permissioned translator. On one side, a website speaks web requests: give me wallet info, send this invoice, create an invoice, sign this message, sign this Nostr event, log this user in, or use this Lightning address. On the other side, the user has wallets, keys, accounts and spending limits. The extension sits between them and asks the user, or the user's saved policy, whether that request should go through.

WebLN turned Lightning into a web interface

WebLN is central to the extension's role. The WebLN guide describes a browser-facing JavaScript interface, `window.webln`, that lets Lightning apps request information, send payments, create invoices and request message signatures through a client application such as a browser extension. That is the user-experience breakthrough. The website does not need to know every node API. It asks a provider in the browser, and the provider handles the wallet side.

This is why Alby became so visible in early Lightning web experiences. A developer could build a Lightning app and expect a WebLN provider to be available. A user could click a pay button and see an extension prompt rather than manually copying invoices between tabs. That is not a small convenience. Payment networks become real in browsers only when actions feel native enough for ordinary sessions. WebLN gave Lightning a web shape, and Alby Extension became one of the most recognized providers of that shape.

The risk is that a clean web interface can hide dangerous context. A site that can ask for a payment may ask too often, ask for too much, or rely on permissions the user no longer remembers granting. That is why budgets and allowances matter. The README and store listing both highlight custom budgets or allowances. They are not just a power-user feature; they are the safety valve that keeps web payments from turning into a blanket authorization.

Nostr signing is a different power

Nostr support is the second half of the extension's importance. NIP-07 defines a browser capability where web pages can ask `window.nostr` for the user's public key and for signatures, instead of asking the user to paste a private key into every client. This changed Nostr web onboarding. A web client could become usable without taking custody of the nsec. The extension becomes the place where the private key stays while websites request signatures.

That does not mean every prompt is harmless. A Nostr event signature can publish a note, update a profile, follow or unfollow people, create lists, react, mute, report, label, zap metadata, join communities or authorize a service depending on the event kind and tags. If the prompt is vague, the user can approve something they do not understand. The browser signer pattern improves key custody but shifts attention to prompt clarity and app trust.

Alby Extension therefore sits in a double-security role. It may authorize Lightning payments and it may sign Nostr events. Those powers overlap socially but not technically. Paying a Lightning invoice is not the same as signing a Nostr event. NWC is not NIP-07. NIP-46 remote signing is not WebLN. A careful article should keep these boundaries explicit because sloppy language is how users end up approving the wrong thing with too much trust.

Multiple wallets, not one magic wallet

The extension supports multiple wallet backends and accounts. The GitHub README mentions multiple Lightning node backends such as LND, CLN and custodial options; the store listings describe managing multiple wallets, connecting an existing wallet or node, and working with Alby Hub and Alby Go. This matters because a browser wallet interface is only as good as the wallet it is attached to. A prompt in the extension may look similar while the underlying custody, liquidity and recovery model differ.

A user connected to Alby Hub has a different mental model from a user using a hosted account service, a node behind Tor through a native companion, or a legacy shared wallet setup. The extension is the face; the backend is the engine. If the user cannot identify the engine, they should not raise spending limits. This is especially true when the extension is used on several websites. A tiny mistake repeated across many permissions becomes a real operational risk.

The extension also represents a transition in Alby's product story. Early Alby was strongly associated with the browser extension itself. The current stack puts Alby Hub, Cloud, Account and Go around it. The extension remains important, but it is no longer the whole Alby mental model. A reader should learn to ask: is this action happening in the browser extension, in Alby Account, in Alby Hub, in an NWC connection, or in the third-party website?

Budgets and allowances are the adult feature

Custom budgets and allowances sound like a convenience feature until you imagine a real website with autopayments, streaming payments, tips, subscriptions or repeated zaps. A prompt for every tiny payment is annoying. A permanent unlimited permission is unsafe. A budget creates the middle ground. It lets the user automate small actions while keeping the blast radius readable. This is one of the features that decides whether browser payments can feel usable without becoming reckless.

The important detail is that a budget should be scoped by site, account and intended use. A content site, a podcast app, a point-of-sale page, a developer playground and a social client do not deserve the same allowance. A small recurring payment tool should not inherit the same authority as a daily wallet interface. Alby Extension can make those distinctions visible, but the user has to care enough to inspect them.

For Nostr zaps, budgets become even more sensitive. A social client can make payment feel like a reaction. That is delightful when amounts are small and consent is clear. It becomes dangerous when a user forgets that a zap is real money, or when an app design blurs likes, reactions and payments. The extension is one of the last places to slow the user down. Good wallet UX lets people enjoy small money without forgetting it is still money.

LNURL, Lightning Address and web authentication

Alby Extension also sits near the older Lightning web standards: LNURL-pay, LNURL-auth and LNURL-withdraw. The README calls out LNURL support, and the Firefox listing mentions LNURL vouchers, LNURL-auth and NIP-07 authentication. These flows are not all the same. LNURL-pay lets a wallet resolve a payment endpoint into invoice details. LNURL-auth lets a wallet-like key participate in login. LNURL-withdraw lets a user pull funds from a service into a wallet. Each flow needs a browser interface that can make the action understandable.

Lightning Address builds on the idea that payment endpoints should be human-readable. Alby's wider product stack uses Lightning addresses heavily, and those addresses often show up in Nostr profile metadata as zap targets. The extension is not the whole Lightning Address system, but it helps the user interact with addresses and invoices in the browser. That is part of why Alby feels like a web product rather than a command-line wallet bolted onto a website.

Authentication is the tricky side. Passwordless login can mean several things: LNURL-auth, Nostr login through NIP-07, app authentication with a wallet, or service login through an account. A user should not assume every login has the same privacy or recovery behavior. The extension can make login easier, but easier login is not automatically safer login. The user still needs to know which identity they are proving and which service receives that proof.

NWC changed what the extension connects to

Nostr Wallet Connect changed the role of browser wallet interfaces because a wallet service can now expose capabilities to apps through Nostr relays. NIP-47 describes encrypted request and response events between a client and wallet service, with connection URIs, relays, client secrets and wallet-service pubkeys. Alby Hub is one of the major NWC wallet-service products, and Alby Extension release notes show ongoing work around NWC connectors and wallet settings.

For the extension, NWC means the browser surface can become one interface among several. A user can approve actions in the browser, connect apps to a Hub, use Alby Go on mobile, and still think of the whole thing as Alby. That coherence is useful, but it hides the connection map. The extension should be understood as the browser interface that may connect to a wallet service, not necessarily as the wallet service itself.

This is also why Alby Extension should not be filed under a generic NWC category and forgotten. Its value is not that it is NIP-47. Its value is that it mediates websites, wallet backends, WebLN, Nostr signing and Alby's evolving wallet stack. A NWC article explains the protocol. An Alby Extension article explains the product moment where a user decides whether a browser request should become a payment or signature.

Privacy and local key handling

The Chrome and Firefox listings both make a strong privacy claim: private keys are encrypted and stored on the user's device, and the product is presented as a way to sign Nostr events without sharing the private key with websites. That is the right direction for browser signing. A site should receive a signature, not the secret that can sign everything forever. The extension model is a custody improvement over pasting an nsec into every web client.

Still, a browser extension is not an abstract cryptographic vault floating above the operating system. It runs inside the browser extension security model. It has permissions. It receives website requests. It stores local data. It updates through browser extension stores or developer builds. It may communicate with wallet backends. It may use native companion mechanisms for special node access such as Tor-connected backends. Every one of those surfaces deserves sober thinking.

The safe rule is simple: keep the extension updated, install only from official sources, review site permissions, use hardware or remote-signing arrangements where appropriate, keep spending budgets small, and separate identities if you use Nostr for materially different contexts. Do not treat local encrypted storage as permission to stop caring. The extension reduces one class of risk and introduces another class of browser-surface risk.

Open source, releases and the maintenance signal

Alby Extension is open-source under the getAlby organization. The repository is large, TypeScript-heavy and actively maintained, with thousands of commits, hundreds of issues and many releases. The open repository matters for trust because users and developers can inspect the extension, report bugs, review changes and follow release history. It does not make the extension automatically safe, but it gives the ecosystem a way to verify and improve it.

The release history is also a good reality check. Recent release notes show ongoing work around onboarding, wallet settings, NWC connectors, pending and failed transactions, localization, bug fixes and under-the-hood cleanup. That tells you the product is not frozen. It is adjusting to Alby Hub, NWC, browser changes and user feedback. A wallet interface that touches money and signing should be expected to keep moving, but movement means users should pay attention to updates.

The issue tracker is useful for a different reason. It reveals the rough edges: browser-specific connection problems, popup behavior, payment history bugs, missing input validation reports, feature requests around LNURL or invoices, NWC connection hangs and signer prompt ideas. A serious article should not hide those edges. They are the cost of building a live browser wallet interface across multiple browsers, sites, protocols and user setups.

Where the extension can fail

The extension can fail at the browser layer. Chrome, Brave, Edge, Firefox desktop and Firefox Android do not behave identically, and extension APIs change over time. Manifest rules, background scripts, permission prompts, content injection, native messaging and store review all shape what the user experiences. A bug that appears to be a wallet bug may be a browser integration bug. This is why the issue tracker includes browser-specific reports.

It can fail at the wallet layer. The backend may not have liquidity, may be offline, may reject a request, may lack support for a method, may have a budget limit, may be connected through a relay that is not behaving, or may have a configuration mismatch. A browser prompt can look fine while the wallet service behind it cannot complete the payment. A useful troubleshooting habit is to ask whether the extension, website, wallet backend or payment network produced the failure.

It can fail at the human layer. Users can approve the wrong prompt, connect the wrong wallet, forget a budget, install a fake extension, confuse Nostr signing with Lightning payment authority, paste secrets into a support chat, or assume an app is safe because it has an Alby button. The extension's job is to reduce these mistakes, not to make them impossible. Readers should treat every signing or payment approval as a real decision.

Who should use it

Alby Extension is a good fit for people who use Nostr and Lightning in a desktop browser and want an interface that can handle both web payments and signing. It is especially useful for users who visit multiple Nostr clients, test Lightning web apps, zap from browser-based social clients, tip creators on websites, log in through Nostr or Lightning, and want an established open-source extension rather than a one-off website wallet.

It is less ideal for users who never use desktop browsers, users who want only a mobile wallet, or users who do not want any signing key in a browser extension. Those users may be better served by Alby Go, a mobile Nostr signer, Amber on Android, a hardware-backed flow, a NIP-46 bunker, or a narrower wallet app. The right tool depends on where the user acts. If the action is in the browser, the extension is natural. If the action is mobile-first, it may not be.

Developers should use the extension as a test surface, but not as the only wallet assumption. If an app works only when Alby Extension is installed and configured a particular way, the developer should say that clearly. Better still, support WebLN, NWC and wallet-connect abstractions thoughtfully so users can bring the wallet interface that fits their custody model. Alby is important, but the ecosystem is healthier when no single extension becomes a silent requirement.

Where it fits on Crays

On Crays, Alby Extension should live under `/nostr/wallets/apps/alby-extension/` because it is a wallet interface and signer. It should also appear on `/nostr/apps/` because many readers will discover it while looking for Nostr clients, signers, apps and developer tools. The Apps hub is a cross-ecosystem shelf; the article route should still teach the right category. For Alby Extension, the right category is wallet interface with browser signing powers.

This classification keeps the Alby family readable. Alby Hub is the wallet service and node-like product. Alby Cloud is hosted Hub infrastructure. Alby Account is the web account and Lightning address layer. Alby Go is the mobile wallet interface. Alby Extension is the browser interface and signer. Alby Discord is a community support space. Alby JS SDK is developer tooling. If all of those collapse into one Alby entry, the reader loses the most important safety distinctions.

The article also helps correct a common Nostr map mistake: NWC relevance does not make everything an NWC wallet. Alby Extension touches NWC, WebLN, NIP-07, LNURL, Lightning addresses and ordinary browser-extension security. It deserves a product-specific explanation because the user does not experience NWC as a spec; the user experiences a browser prompt, a site permission and a wallet action.

The practical verdict

Alby Extension is one of the core bridges that made Lightning and Nostr usable on the web. It gave websites a way to ask for payments and signatures without becoming private-key custodians. It gave users a familiar prompt instead of raw invoice handling. It gave developers a target for WebLN and Nostr browser signing. In that sense, it belongs in any serious map of Nostr apps and tools.

The same bridge is why readers should treat it with respect. Browser prompts can become muscle memory. Permissions can outlive their original context. Wallet backends can change. Extensions can have bugs. Store listings can lag reality. A good setup uses official installs, small budgets, clear wallet separation, careful site permissions and regular review of connected apps. The right posture is not fear; it is attention.

If you use Nostr and Lightning mostly in the browser, Alby Extension is still one of the most practical starting points. Just remember what it is: a browser wallet interface, a WebLN provider, a Nostr signer and a bridge to Alby's wider wallet stack. It is not your whole identity, not your whole wallet strategy and not a reason to stop reading prompts. Used carefully, it turns web payments and signing from a chore into a habit you can control.

Sources worth opening

The strongest sources are the extension's own GitHub repository, the Chrome and Firefox listings, release notes, WebLN documentation, Alby's product pages and the NIPs for browser signing, remote signing, wallet connections and zaps.

• Alby official site
• Alby pricing and product comparison
• Chrome Web Store - Alby Bitcoin Wallet for Lightning and Nostr
• Firefox Add-ons - Alby Bitcoin Lightning Wallet and Nostr
• getAlby/lightning-browser-extension repository
• Alby Extension releases
• Alby Extension issues
• Alby Extension security file
• Alby Extension setup documentation
• WebLN Guide
• NIP-07 - window.nostr browser signer capability
• NIP-46 - remote signing
• NIP-47 - Nostr Wallet Connect
• NIP-57 - Lightning Zaps
• NIP-01 - basic Nostr protocol flow
• Alby Hub user guide
• Alby Go user guide
• Alby Developer Guide - Nostr Wallet Connect API
• Nostr Wallet Connect official site
• Bitcoin Connect
• Alby Feedback Forum
• Alby Help
• Alby Terms of Service
• Alby Privacy Policy
• Mozilla MDN - Native messaging
• Chrome Extensions documentation
• getAlby organization on GitHub