Alby Lightning Wallet: From Zero to Sovereign AI Tipper in 30 Minutes

Lightning wallets are the private, instant way to pay for AI services without giving your identity to Visa. Alby ^↗ makes this dead simple.

Quick Take

• Install Alby in your browser or phone today
• Claim your name@alby.com Lightning address in under 5 minutes
• Start receiving Zaps on Nostr without exposing your on-chain address
• Keep your seed phrase on a metal plate, not in the cloud

Claim Your Lightning Address Before Someone Else Does

# Chrome: https://chrome.google.com/webstore/detail/alby/
# Firefox: https://addons.mozilla.org/en-US/firefox/addon/alby/
# Mobile: Alby Go app from the App Store or Play Store

# Step 2: Open Alby → Settings → Lightning Address → Choose username
# Example: if you pick "magnetic", your address becomes magnetic@alby.com

Alby’s Lightning address is defined as a human-readable identifier that routes payments directly to your node’s liquidity pool. This matters because it replaces long, error-prone invoices with a simple name@alby.com that works everywhere from podcast show notes to Nostr profiles. In practice, claiming your address early prevents username squatting, once taken, it’s gone forever.

Gotcha: Alby’s LNURL server acts as a middleman. If it goes down, your address stops working until it’s back. For true sovereignty, run your own Lightning node or use a self-hosted LNURL gateway.

Receive Your First Zap Without On-Chain Fees

// 1. Open a Nostr client like Primal (https://primal.net)
// 2. Click the ⚡ icon under any post
// 3. Alby extension pops up asking for permission
// 4. Confirm amount (e.g., 100 sats) and click "Send"

Zaps are Lightning payments triggered by Nostr events. They’re defined as instant, low-fee tips that don’t require the recipient to expose a static on-chain address. This matters because it lets you monetize content without the privacy leaks of traditional crypto donations. In practice, a 100-sat Zap costs less than a penny and confirms in seconds, ideal for tipping small AI research posts.

Gotcha: If your Lightning address isn’t set in your Nostr profile, Zaps won’t reach you. Add it under Settings → Profile → Lightning Address.

Split Your Budget So You Don’t Accidentally Tip the IRS

// 1. Alby → Settings → Sub-Wallets → Create New
// 2. Name it "AI Tips" and set a monthly limit of 50,000 sats (~$5 at current rates)
// 3. Use this wallet only for Nostr Zaps and AI service payments

Sub-wallets are defined as isolated Lightning balances that share a single seed phrase but enforce separate spending rules. This matters because it prevents one impulsive Zap from draining your entire stack. In practice, a 50,000-sat monthly cap on “AI Tips” keeps your Sovereign AI budget predictable without locking you out of emergencies.

Gotcha: Sub-wallets share liquidity. If your main wallet runs dry, the sub-wallet can’t spend either. Keep a small buffer in your main wallet for channel rebalancing.

Self-Host Your Node When Alby’s Servers Aren’t Enough

# 1. Install Umbrel on a Raspberry Pi 5 (8GB) or DGX Spark
# 2. Add the Alby Hub app from Umbrel’s app store
# 3. Connect Alby extension to your node’s REST endpoint

Alby Hub is defined as a self-hosted Lightning node that replaces Alby’s default routing servers. This matters because it gives you full control over liquidity, privacy, and uptime, critical when you’re running AI workloads that can’t wait for a third-party node to come back online. In practice, a self-hosted node means you can accept Zaps even if Alby’s LNURL server is down, and you avoid paying routing fees to external hubs.

Gotcha: Running your own node requires opening inbound channels. If your ISP blocks port 9735, use a VPS with a static IP or a Tor-based solution.

Next step in this series: if you decided you want the self-hosted route, the Alby Hub on ARM64 guide walks through the Docker setup, channel opening, and isolated sub-wallets end to end. Same author, same blog, same wallet.

What I Actually Use

• Alby extension: because I want one click to pay for Mistral Small 4 API calls without exposing my identity
• BitBox02 ^↗: for cold storage of anything over $100 worth of sats
• Primal on iOS: because the mobile app’s Zap button is faster than typing a Lightning invoice

Why no-KYC actually matters here

The KYC-vs-no-KYC distinction is not philosophical posturing for a Lightning wallet at this scale. It is operational. KYC wallets ask for documentation that, in many jurisdictions, also creates tax-reporting obligations on the wallet operator. That is fine for high-volume traders and weird for someone using Lightning to receive blog tips. KYC also creates a single point of regulatory risk: if the wallet provider changes policy, the user has to migrate or lose access. Alby’s no-KYC tier is the right default for the use case.

Backup discipline that earns its keep

Wallet backup advice tends to be either too vague (“write down your seed”) or too specific to one threat model. The mitigation that has worked here is two backups in two locations plus one quarterly test. The first backup is the seed words on paper, stored somewhere not co-located with the wallet device. The second is the seed words on a metal seed-storage plate, stored somewhere geographically separate from the first. Quarterly: restore one of them to a fresh Alby account, send a test zap to a known-good address, confirm it lands. Most lost-funds incidents in 2024-2025 were not technical failures; they were human failures of recovery procedure that surfaced only when recovery was needed for the first time and the seed was wrong, faded, or filed somewhere nobody remembered.

Tipping discipline that does not become accidental tax-event volume

The split into editorial-tipping versus commerce-checkout versus zap-receiving is the operational pattern that prevents a Lightning wallet from accidentally becoming a high-volume payment terminal. Editorial tipping (sending zaps to authors I read) goes through one Alby account with a small balance. Commerce checkout (paying for actual goods/services) goes through a separate wallet (or BitBox custodial flow). Zap-receiving on this blog goes through a third Lightning address dedicated to that surface. Three flows, three audit trails, three different “what did this address actually do this quarter” answers when tax season asks. Aggregating them into one wallet is convenient and the wrong tradeoff for anyone who might ever need to explain their Lightning activity.

The single decision that pays back the most over time is treating the Lightning address as infrastructure that survives the wallet. The Lightning address is cipherfox@sovgrid.org; it routes today to Alby; tomorrow it could route to LNbits or a self-hosted Phoenix node, and the routing change is a DNS-level swap that does not require anyone who has zapped me before to know anything new. That portability is the property that makes the Lightning-address spec a meaningful upgrade over raw bolt11 invoices for receiving micro-payments. It also means the wallet choice is reversible without losing the address brand, which lowers the cost of getting it wrong on the first try.

A note on what this article cannot tell you yet: the actual receive-volume on this Lightning Address is currently zero zaps over the first 30 days live. The wallet, the NIP-05 verification, and the relay routing all work end-to-end (verified with test zaps from a separate Alby account). What is missing is the upstream signal of readers acting on what they read with a Lightning send. The full postmortem on that result and the 60-day decision tree on whether to keep the V4V infrastructure is in the zap-tracking post. The Alby setup below is correct regardless of whether the receive side ever produces volume, it costs nothing to leave running and is ready the moment the distribution side works.

The Lightning-address pattern is generally documented to work best when the receiving identity is unambiguous: cipherfox@sovgrid.org reads as a person, info@sovgrid.org reads as a generic inbox. Whether persona-attached addresses outperform brand-attached addresses on a small blog is something I cannot yet quantify against my own data. Reporting it here as a hypothesis worth testing rather than as a measured outcome.