CraysAlby Account
Alby Account is not just the yellow wallet logo. It is the web account, Lightning address, Nostr identity, notification and app-connection layer that ties Alby's extension, mobile wallet and self-custodial Hub into one usable payment identity.
The account layer people actually meet first
Alby Account is easy to collapse into the word Alby, but that would make the map less useful. Alby Hub is the self-custodial wallet service. Alby Extension is the browser signer and web wallet surface. Alby Go is the mobile interface. Alby Account is the account layer around them: the hosted profile, Lightning address, dashboard, email identity, notifications, app-management surface and commercial service relationship.
That account layer matters because most people do not begin with a node. They begin with a login, a Lightning address, a browser extension or an app that says connect with Alby. The Account is often the bridge that makes the whole stack feel coherent. It gives the user a place to see activity, manage wallet and app links, receive payments, configure identity and connect to services that do not know how to talk directly to a self-hosted Lightning node.
For a Nostr map, Alby Account sits between Wallets and Apps. It is a wallet interface, but it also touches Nostr identity, NWC app connections, browser signing and creator payments. If it is buried under a generic Alby page, readers miss the most important distinction: an account service is not the same object as a local key, a Hub recovery phrase, a browser signer or a Lightning channel.
What the Account gives the user
The public Alby product site presents the brand around connecting to apps, paying on the web, creating or connecting a wallet and using a Lightning address. The account guide explains that an Alby Account can be used to receive payments, connect apps, manage funds, use wallet features and work with Alby products such as Hub, Extension and Go. In plain language: it is the dashboard and identity layer for the user-facing Alby experience.
The Lightning address is the easiest feature to understand. Instead of sharing an invoice every time, a user can receive at an email-like address. That gives creators, writers, podcast hosts, Nostr users and small businesses a payment endpoint they can put in profiles and apps. On Nostr, that endpoint often shows up in the `lud16` profile field that clients use for zaps.
The dashboard is the second feature. A person can see payments, invoices, app links and account settings in one web surface. That sounds mundane, but it is what turns raw Lightning into a product. Without the dashboard, the user is left stitching together wallet state, app authorizations, email notifications and Nostr settings by memory. With the dashboard, there is at least one place to return to.
The difference between Account and Hub
Alby Hub and Alby Account are deliberately connected, but they are not the same thing. Alby Hub is the wallet service that can run self-custodially and serve NWC app connections. Alby Account is the hosted account layer that can provide a Lightning address, notifications, app discovery, support links and account services. The Hub docs recommend linking an Alby Account during setup because it unlocks practical features, but they also make clear that Hub is the wallet-control side.
This distinction is not philosophical hair-splitting. It changes the trust model. When a user runs Alby Hub locally or on a server, the user takes on backup, uptime and wallet-state responsibility. When the user relies on Alby Account services, the user also depends on Alby's hosted web infrastructure, domain, account system and policies. Most users will want both. The archive should help them understand which layer is doing which job.
A useful phrase is: Account is the address and service relationship; Hub is the wallet engine. That phrase is not perfect because Alby has multiple wallet surfaces, but it points the reader away from the common mistake of thinking every Alby feature has identical custody and recovery behavior.
Nostr identity starts with more than a pubkey
Nostr identity is technically a key pair, but products turn that key into something people can use. Alby Account participates in that product layer by connecting payment identity, browser extension behavior, profile metadata and Nostr app connections. The Alby ecosystem has long been important in Nostr because it made zaps and web signing approachable before many users understood the protocol pieces.
NIP-05 is the Nostr pattern for mapping a public key to an internet identifier. Lightning Address and LNURL give a similar human-readable payment shape. When an Alby user has both a recognizable identity and a reachable Lightning address, Nostr clients can render a profile that feels much less alien. The user has a name-like handle, a payment endpoint and app support. That is the difference between protocol capability and product confidence.
The risk is that convenience can blur objects. A Nostr public key, a browser signer secret, a Lightning address, an Alby Account login, a Hub password and a wallet seed are not interchangeable. The Account helps coordinate them, but it is not itself the whole account in the Nostr sense. A serious user learns which key signs, which service receives, which app spends and which backup recovers.
App connections are where the Account becomes operational
Alby has spent years making apps easier to connect. The account guide and app-connection surfaces point users toward a wider marketplace of clients, publishers, podcasting tools, websites and wallets. In modern Alby, this points toward NWC: apps can request wallet powers through a connection rather than asking the user to pre-fund every platform.
The Account helps make those relationships legible. It is where the user can understand that an app is connected, that payments are flowing through a certain wallet service and that notifications or wallet surfaces belong to the same identity. If the Hub is the engine, the Account is often the dashboard that makes the engine feel less lonely.
This is also where a user should slow down. App connections are not bookmarks. They can carry payment permissions, recurring behavior, notification hooks or wallet access. An Account dashboard that makes those connections visible is a major safety feature. The user should still read what each app can do, keep budgets small and disconnect tools that are no longer needed.
Alby Extension depends on the Account story
The Alby Browser Extension deserves its own entry, but the Account is part of why the extension became a default mental model for many web users. A person installed the extension, connected a wallet or account, and suddenly web pages could request Lightning payments or Nostr signatures through a familiar browser surface. That was a big product translation moment for Nostr and Lightning.
The extension can work with Alby Account and Alby Hub in different ways. That is why a reader needs separate articles. The Account is not only a login for the extension; it is a place where payment identity, app discovery and support sit. The extension is the thing that appears in the browser at the moment of action. Confusing those two leads to bad security language.
A clean product map says: Account is the web service and identity layer; Extension is the browser interface and signer/payment bridge; Hub is the wallet service; Go is the mobile interface. The overlap is intentional, but the boundary is where trust decisions live.
Alby Go and mobile continuity
Alby Go is Alby's mobile wallet interface, and it also benefits from the Account layer. A user who wants to carry the Alby experience away from the desktop needs a mobile surface that understands their wallet connection and payment identity. The Account helps make that continuity feel normal because it gives the user a stable service relationship across products.
For Nostr, mobile continuity is especially important. People do not only zap from desktop web clients. They read notes, scan QR codes, click Lightning addresses, open podcast apps and approve payments from phones. An Account that ties together notification, address and connection state can reduce friction, provided users still understand where signing and spending permissions live.
The tradeoff is familiar: synchronized convenience adds infrastructure. If your mental model depends on the Account being reachable, email being available and Alby services staying online, then those services become part of your operational path. That may be entirely acceptable. It just should not be mistaken for a purely local wallet.
Creator payments and podcasting
Alby Account has always made sense for creators because creators need a public payment identity more than they need a lecture about channels. A Lightning address can sit on a profile, a blog, a podcast, a Nostr bio or a donation page. Alby's docs and ecosystem references include podcasting and app integrations because value-for-value media was one of the earliest places Lightning payments felt socially natural.
Podcasting 2.0 and Nostr zaps are not the same system, but they rhyme. Both ask whether a listener can send small payments to a creator in the flow of attention. Both need wallet UX, recipient metadata and clear fee behavior. An Alby Account can be the bridge that makes those payments reachable without forcing every creator to run a node first.
For Crays, this matters because creator and venue experiences depend on boring reliability. A musician, writer, podcast host or event organizer does not want to debug raw LNURL responses. They want a payment identity that clients recognize. Alby Account is one of the products that turned that desire into a mainstream Bitcoin/Nostr onboarding path.
Top-ups, invoices and the ordinary wallet chores
A good wallet interface handles the unglamorous things: receiving, sending, invoices, balances, withdrawals, account settings, notifications and recovery paths. Alby Account is where many of those chores become visible to nontechnical users. The project should be judged not only by whether it supports a protocol, but by whether it makes those chores understandable.
Top-ups and purchases deserve care. When a product helps users buy bitcoin or move funds, legal, payment-provider and regional constraints can enter the picture. An account interface may show options that depend on jurisdiction, third-party providers or current Alby plan status. The article should not freeze those options as permanent. It should teach the reader to identify the service boundary.
Invoices are similarly ordinary and important. A user may receive through a Lightning address, generate an invoice, pay from a connected wallet or authorize an app connection. Each path has different failure cases. If a payment fails, the user needs to know whether the problem is the account service, the wallet backend, the app, the relay, liquidity or the recipient address.
Pricing and plan reality
Alby now has a more explicit product stack than the early extension days: Account, Hub, Cloud, app connections and support all live inside a business. Pricing pages can change, but the important point is stable: some Alby features are free or open-source, while others are paid hosted services or plan-dependent conveniences. That is normal. It should be transparent in the user's mental model.
The Account is where the commercial relationship becomes visible. A user may pay for cloud hosting, plan features, support or related services. That does not make the product less open in the areas where it is open-source. It means the reader should separate protocol capability from business service. A free Nostr key does not pay for hosted infrastructure, customer support or always-on wallet availability.
For Crays readers, the practical advice is simple. Use the Account where it saves friction. Use Hub where you want wallet control. Pay for hosted services when the convenience is worth it. But do not assume the same recovery, privacy and uptime guarantees apply to every layer just because the logo is the same.
Privacy and account risk
Alby Account necessarily sees more of the user relationship than a purely local signing tool. It can involve email, account settings, payment notifications, connected services and plan management. Alby's privacy policy and terms therefore matter. A privacy-sensitive user should read them with a specific question: what data belongs to the hosted Account layer, and what data stays in the wallet or signer layer?
The main risk is not that Alby is unusually suspicious. The risk is category confusion. Users sometimes hear self-custody and then stop asking which services still see metadata. A Lightning payment can reveal timing, amounts and endpoints. A web account can reveal login and notification metadata. A Nostr profile can reveal public social activity. Combining them is useful, but it creates a richer picture.
The good habit is to choose the right surface for the job. Use public Lightning addresses when being reachable matters. Use careful app permissions when spending matters. Use self-hosted Hub when control matters. Use Account services when convenience and support matter. Privacy is not a switch; it is a stack of choices.
How to test Alby Account
Create or inspect an Alby Account with a tiny balance and a low-stakes identity. Confirm the Lightning address. Send a small payment to it. Send a small payment out. Check whether notifications arrive. Then connect one app, preferably through a wallet connection with a small budget, and watch how the activity appears in the Account and wallet surfaces.
Next, connect the account to Alby Extension and compare what each surface shows. Which actions happen in the browser? Which actions happen in the web dashboard? Which actions require Alby Hub or another wallet backend? If you cannot explain that to yourself after testing, do not scale up yet.
Finally, test removal. Disconnect an app. Change a setting. Confirm whether the old connection still works. Wallet safety is not only about adding integrations; it is about being able to undo them cleanly. Alby Account earns its place when it makes that undo path visible.
Why it deserves its own page
Alby Account deserves its own page because it is the layer where normal users understand Alby. Hub, Extension and Go are all clearer when Account is not treated as background plumbing. It is the public address, dashboard, notification system, plan relationship and app connection context around the more technical wallet pieces.
It also deserves scrutiny because hosted convenience is where many open-protocol products win or lose users. A user may support self-custody in principle but still choose the tool that gives them a readable address, a recovery path, a clean dashboard and helpful notifications. Alby Account is one of the products trying to make that compromise feel humane.
The right conclusion is not to call it perfect or dismiss it as centralized. The right conclusion is to locate it precisely. Alby Account is a wallet interface and service layer for Lightning and Nostr users. It makes payments easier, app connections more legible and identity more usable. It also introduces account-service dependencies that the user should understand before treating it as invisible.
Sources worth opening
Start with Alby's account and guide pages, then compare the account layer with Alby Hub, NWC, Lightning Address, LNURL and Nostr identity documents.
- Alby official site
- Alby Account guide
- Alby Account features guide
- Alby guide: connect to apps
- Alby Hub guide
- Alby Hub getting started
- Alby Hub app connections
- Alby Browser Extension guide
- Alby Go guide
- Alby pricing
- Alby support
- Alby privacy policy
- Alby terms
- Alby Hub GitHub repository
- Alby JS SDK
- Bitcoin Connect
- Nostr Wallet Connect site
- NIP-47 Nostr Wallet Connect
- NIP-57 Lightning Zaps
- NIP-05 DNS identifiers
- NIP-07 browser signer capability
- Lightning Address
- LNURL LUD-16 Lightning Address
- Podcasting 2.0 value specification
- WebLN guide
