Alby + Nostr: Send Lightning Zaps with Sovereign Identity

Lightning wallets can’t sign Nostr events, and most Nostr clients force you to paste your private key into a web page. That’s a security disaster waiting to happen.

import { nip07 } from 'nostr-tools'

// Alby exposes window.nostr
const pubkey = await window.nostr.getPublicKey()
const event = {
  kind: 1,
  created_at: Math.floor(Date.now() / 1000),
  tags: [],
  content: 'First sovereign post'
}
const signed = await window.nostr.signEvent(event)
console.log(signed)

In practice you never touch the private key, Alby ^↗ holds it inside the extension and only returns signatures.

Quick Take

• Nostr identities are keypairs: your public key (npub) is your address, your private key (nsec) is your identity
• NIP-07 lets a browser extension sign events without exposing the private key
• Zaps are Lightning payments sent directly to a user’s Lightning address

Generate a Nostr Keypair with Alby

A Nostr identity is a keypair you own forever. Alby creates it for you inside the extension so you never have to copy-paste secrets into a web form.

npub1q8fvq...  # public key, safe to share
nsec1q9gx...  # private key, keep offline

In practice the nsec is your master password, whoever holds it controls your identity and can post as you.

Publish a Lightning Address for Zaps

Without a Lightning address, users can’t zap you. Alby gives you a custodial Lightning address you can drop straight into your Nostr profile.

# In Primal → Profile → Lightning Address
deinname@alby.com

In practice the address is an Alby subdomain that forwards incoming zaps to your wallet.

Connect a Nostr Client to Alby

NIP-07 works wherever the client asks the browser for signatures. Tested clients:

Primal web Snort social iris.to Damus iOS

Connecting (Primal example):

1. Open primal.net
2. Click "Login with Extension"
3. Alby pops up: "Allow primal.net to access your public key?"
4. Confirm → profile loads

In practice the client never sees your private key, only the signed event you approve in the extension.

Send a Lightning Zap from Your Browser

Zaps are Lightning payments attached to Nostr events. They go directly to the recipient’s Lightning address without intermediaries.

# In Primal → any post → click ⚡
Amount: 21 sats
Message: "Keep building"
Confirm in Alby

In practice the zap amount is denominated in satoshis and the payment settles in seconds.

Relay Setup for Reliable Delivery

Relays are servers that forward your posts to followers. More relays equals wider reach.

Default relays (automatic in most clients):

wss://relay.damus.io
wss://relay.nostr.band
wss://nos.lol

Paid relay (better uptime, less spam):

wss://relay.primal.net

In practice you can add or remove relays in Alby’s Nostr settings without touching the client.

Privacy Without Anonymity by Default

Nostr is censorship-resistant but not anonymous. Your public key links every post you make.

For stronger privacy use a separate key for public posts and route traffic through Tor.

What I Actually Use

• Alby browser extension: because it’s the only NIP-07 signer that keeps my private key offline
• Primal web client: because it combines the best UX with built-in zap discovery

Why bundling Alby-the-wallet with Nostr-the-protocol is right today

The intuitive criticism of using one provider for both Lightning wallet and Nostr key management is “you should not put both keys in one place”. That criticism is valid in general and wrong in this specific case for a reason worth naming. Alby’s Nostr integration uses NIP-46 (bunker pattern) where the actual signing key is encrypted client-side and Alby holds an opaque blob it cannot decrypt without your password. The Lightning side is custodial in the conventional sense (Alby holds the funds, you trust them not to disappear with them). The risk profile is therefore different on each side: Lightning custody risk plus Nostr-key encryption-at-rest risk, not the same risk twice.

For amounts that justify cold storage (anything above the convenience threshold of ~100k sats for active Lightning use), the right pattern is to keep large balances on a hardware wallet (BitBox ^↗, Coldcard) and only the working-balance on Alby. The Nostr-keys-in-Alby pattern stays valid because the encryption boundary is solid; the Lightning-funds-in-Alby pattern needs balance discipline to stay solid.

The signing-service alternative for higher-stakes use

If the Alby-bundled pattern feels too coupled, the architectural alternative is a dedicated signing service: NIP-46 bunker hosted on infrastructure you control (a small VPS, a home server, even a Raspberry Pi), with the Nostr clients connecting via the bunker URI rather than via Alby’s hosted endpoint. The tradeoff: more infrastructure to maintain, but stronger separation between Lightning custody and Nostr key custody. For solo use, Alby-bundled is the right starting point. For multi-persona setups (running a blog with cipherfox plus hexabella identities, for example), the dedicated signing service starts paying off.

What goes wrong on first connection, and how to recover

The most common first-connection failure mode is not Alby’s fault but Nostr-client-side: the client expects a NIP-46 connection URI in a specific format, and the URI Alby generates may not match what your client expects. The fix is usually one of three things: paste the URI into a different client to verify the URI itself works, regenerate the URI from the Alby Settings page in case the previous one was malformed, or check the client’s NIP-46 docs for known compatibility quirks. Damus, Amethyst, and Snort each have slightly different bunker-URI parsing; what works in one may need a tweak in another.

The Lightning-address-publish step also has a common gotcha: the address gets published to your Nostr profile metadata, but if your client caches profile metadata aggressively, the new address may not propagate to other clients for hours. The fix is either patient (wait for cache expiry) or active (republish the kind-0 metadata event from a different client to force propagation).

The Lightning-address-published-to-Nostr-profile pattern has a non-obvious side effect worth knowing: zaps to that address now show up in your Nostr feed as zap-receipt events, which means your zap activity is publicly visible by default. For most use cases that is fine (transparent V4V is a feature, not a bug). For use cases where you would prefer that activity stay private, the workaround is to use a dedicated zap-receiving identity separate from your main Nostr identity. That separation costs almost nothing to set up and gives back the privacy floor for cases where it matters.

The single closing observation that ties the Alby plus Nostr setup back to the rest of the Sovereign AI Grid stack: this is the same pattern at every layer. A privacy-respecting commercial provider for the convenience tier (Alby for Lightning, Floki for VPS, BitBox for cold storage), a self-hosted alternative behind it for the high-stakes case (LNbits or Phoenix for Lightning, your own VPS or hardware for hosting, multisig with multiple devices for cold storage). The Alby-bundled flow is the convenience tier of the privacy-respecting option for Nostr signing. When the use case crosses the threshold where convenience-tier risk stops being acceptable, the migration path to the self-hosted tier exists and is documented. That two-tier pattern, repeated across every layer of the stack, is the reason the whole thing feels coherent rather than ad hoc.

Where to go next. This article is part 2 of the Alby series on this blog. Part 1 (Alby Lightning Wallet) covers the browser extension and Lightning addresses for readers starting from zero. Part 3 (Alby Hub on ARM64) is the self-hosted upgrade: your own Lightning node in Docker on a Raspberry Pi, mini PC, or DGX Spark, with isolated sub-wallets per app.