readme

README.md

@@ -1,11 +1,11 @@
 # Lightning.Pub
 
-![Lightning.Pub](https://github.com/shocknet/Lightning.Pub/raw/master/pub_logo.png)
+![Lightning.Pub](https://github.com/shocknet/Lightning.Pub/raw/wizard-update/pub_logo.png)
 
 ![GitHub last commit](https://img.shields.io/github/last-commit/shocknet/Lightning.Pub?style=flat-square)
 [![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](http://makeapullrequest.com) 
 [![Chat](https://img.shields.io/badge/chat-on%20Telegram-blue?style=flat-square)](https://t.me/ShockBTC)
-![X (formerly Twitter) Follow](https://img.shields.io/twitter/follow/ShockBTC?style=flat-square&logo=bitcoin)
+![Xitter](https://img.shields.io/twitter/follow/ShockBTC?style=flat-square&logo=bitcoin)
 
 ### Don't just run a Lightning Node, run a Lightning Pub.
 
@@ -15,7 +15,9 @@ Lightning payments open the door to a new internet, but because of UX challenges
 
 It may come as a surprise that the biggest hurdle to more adoption via Family and SMB Lightning nodes hasn't been with Bitcoin/Lightning node management itself, as we've seen that liquidity is easily automated, but rather the legacy baggage of traditional Client-Server web infrastructure. Things like IP4, Reverse Proxies, DNS, Firewalls and SSL certificates, all require a personal configuration that is a hurdle for most.
 
-Tor as a workaround has proven too slow and unreliable, and a dead-end for clearnet-web usecases. Mobile node are easy but channels for every device is expensive and unscalable, and the UX that suffers from the limitations of the node not being an always-online server.
+Tor as a workaround has proven too slow and unreliable, and a dead-end for clearnet-web usecases. 
+
+Mobile nodes are easy to use for spending, but channels for every device is expensive and unscalable. UX suffers from the limitations of the node not being an always-online server, which also makes them largely useless for merchants and routing services that earn revenue while you sleep.
 
 Pub solves these challenges with a P2P-like design that is also web-friendly, by implementing a full RPC that is Nostr-native. Being Nostr-native eliminates the complexity of configuring your node like a server by using commodity Nostr relays. These relays, unlike LNURL proxies, are trustless by nature of Nostr's own encryption spec (NIP44).
 
@@ -31,18 +33,27 @@ By solving the networking and programability hurdles, Pub provides Lightning wit
   - [Docker Installation](#docker-installation)
   - [Manual CLI Installation](#manual-cli-installation)
 - [Usage Notes](#usage-notes)
-- [Misc](#support-development)
+  - [Connecting to ShockWallet](#connecting-to-shockwallet)
+  - [Lightning Address](#lightning-address)
+  - [Node Type](#node-type)
+  - [Running Your Own Nostr Relay](#running-your-own-nostr-relay)
+  - [Bootstrap vs Self-Hosted Mode](#bootstrap-vs-self-hosted-mode)
+  - [Configuration](#configuration)
+- [Support Development](#support-development)
 
 ## Features
 
+- **Zero Network Configuration Required** - No port forwarding, Tor setup, firewall rules, or DNS configuration needed! Pub uses Nostr relays for all communication, making it perfect for users who want sovereignty without networking complexity.
 - Wrapper for [`LND`](https://github.com/lightningnetwork/lnd/releases) that can serve accounts over LNURL and NOSTR
 - A growing number of [methods](https://github.com/shocknet/Lightning.Pub/blob/master/proto/autogenerated/client.md)
 - Automated Channels
   - Receives quotes from multiple LSPs including Zeus, Voltage, and Flashsats
 - Bootstrap Peering
   - A pub node may trust another pub node until it can afford a channel 
+  - Can be disabled via environment variable for full sovereignty
 - Accounting SubLayers for Application Pools and Users 
   - A fee regime allows applications owners to monetize users, or node operators to host distinctly monetized applications.
+- **Complete Lightning Solution** - No additional LN node or Bitcoin full node required (uses Neutrino)   
 
 ![Accounts](https://github.com/shocknet/Lightning.Pub/raw/master/accounting_layers.png) 
 
@@ -74,8 +85,17 @@ This method installs all dependencies and creates user-level systemd services.
 
 **Platform Support:**
 - ✅ **Debian/Ubuntu**: Fully tested and supported
-- ⚠️ **Arch/Fedora**: Should work but untested - please report issues
+- ✅ **Arch/Fedora**: Fully tested and supported
-- 🚧 **macOS**: Basic support stubbed in but completely untested - help wanted
+- 🚧 **macOS**: Basic support stubbed in, but untested. Help wanted.
+
+> [!IMPORTANT]
+> **System Requirements:**
+> - **RAM**: Minimum 2GB burstable in headless containers or VPS. 4+GB recommended for full Linux Desktop OS.
+> - **Storage**: 20GB of space for compact blocks.
+> - **Network**: No port forwarding, Tor, or firewall configuration needed! Pub uses Nostr relays for communication to eliminate traditional server networking requirements.
+
+> [!TIP]
+> **Bundled Node**: The Lightning.Pub install script provides a complete Lightning solution. You do NOT need to a full Bitcoin or other node, perfect small devices like Raspberry Pi.
 
 To start, run the following command:
 
@@ -90,7 +110,11 @@ It should look like this in a minute or so
 **Note:** The installation is now confined to user-space, meaning:
 - No sudo required for installation
 - All data stored in `$HOME/lightning_pub/`
-- Logs available at `$HOME/lightning_pub/install.log`
+
+**After Installation:**
+- The installer will display an admin connection string (nprofile and secret separated by a colon) and a **QR code** for easy mobile setup
+- You can also access the connection info via web browser on Start9 and Umbrel appliances (releases forthcoming)
+- Copy the connection string or scan the QR code with ShockWallet to connect as administrator
 
 **⚠️ Migration from Previous Versions:**
 Previous system-wide installations (as of 8.27.2025) need some manual intervention:
@@ -113,6 +137,32 @@ These are controversial, so we don't include them. You can however add a line to
 
 **Note:** The installer will only restart services if version checks deem necessary.
 
+#### Troubleshooting
+
+If the installation fails or services don't start properly, use these commands to diagnose:
+
+```bash
+# Check service status
+systemctl --user status lnd
+systemctl --user status lightning_pub
+
+# View logs
+journalctl --user-unit lnd -f
+journalctl --user-unit lightning_pub -f
+
+# Restart services if needed
+systemctl --user restart lnd
+systemctl --user restart lightning_pub
+
+# Retrieve admin connection string (if installation completed but you need to find it again)
+cat ~/lightning_pub/admin.connect
+
+# Reset admin access (generates new admin.connect automatically)
+rm ~/lightning_pub/admin.npub
+sleep 1  # Wait briefly for new admin.connect to re-generate
+cat ~/lightning_pub/admin.connect
+```
+
 ### Docker Installation
 
 See the [Docker Installation Guide](DOCKER.md).
@@ -145,11 +195,75 @@ npm start
 
 ## Usage Notes
 
-Connect with ShockWallet ([wallet2](https://github.com/shocknet/wallet2)) using the wallet admin string that gets logged at startup. Simply copy/paste the string into the node connection screen.
+### Connecting to ShockWallet
 
-The nprofile of the node can also be used to send invitation links to guests via the web version of ShockWallet.
+**For Administrators:**
+1. After installation, you'll see an admin connection string (format: `nprofile1...:token`) and a QR code
+2. **Option 1**: Scan the QR code with ShockWallet mobile app
+3. **Option 2**: Copy/paste the connection string into ShockWallet's node connection screen
 
-**Note that connecting with wallet will create an account on the node, it will not show or have access to the full LND balance. Allocating existing funds to the admin user will be added to the operator dashboard in a future release.**
+**For Guest Users:**
+- The nprofile of the node (without the admin token) can be used to send invitation links to guests via the web version of ShockWallet
+- The nprofile is stored in `$HOME/lightning_pub/app.nprofile` or the administrator can copy a link from the "Invite" page in ShockWallet
+
+> [!NOTE]
+> Connecting with wallet will create an account on the node, it will not show or have access to the full LND balance. Allocating existing funds to the admin user will be added to the operator dashboard in a future release.
+
+### Lightning Address
+
+When you run your own Lightning Pub, obtaining a Lightning Address is fully automated in ShockWallet. The wallet automatically:
+1. Takes the CLINK offer from your Pub
+2. Enrolls it at a LNURL bridge (creates a `@shockwallet.app` address)
+3. This makes the Lightning Address trustless when payers support CLINK as it uses Nostr for communication instead of trusting the bridge to serve the correct invoice.
+
+> [!TIP]
+> **CLINK Integration**: Your Pub's CLINK offers enable ShockWallet to connect to CLINK-compatible services, like [Stacker News](https://stacker.news), allowing you to send and receive payments without additional setup.
+
+**Alternative Options for Custom Lightning Addresses:**
+
+1. **Run your own [Bridgelet](https://github.com/shocknet/bridgelet)**: A minimalist LNURL-P and Lightning Address bridge service that uses CLINK Offers. This gives you full control over your Lightning Address domain without trusting third-party bridges.
+
+2. **Enable LNURL directly on Pub**: Set `SERVICE_URL` to your domain (e.g., `https://yourdomain.com`). Pub will serve LNURL callbacks directly. Requires an SSL reverse proxy pointing your domain to Pub's port.
+
+### Running Your Own Nostr Relay
+
+By default, Lightning.Pub uses the ShockNet relay. To use your own Nostr relay:
+
+1. Set the `NOSTR_RELAYS` environment variable in your `.env` file:
+   ```bash
+   NOSTR_RELAYS=wss://your-relay-url.com
+   ```
+2. Multiple relays can be specified (space-separated):
+   ```bash
+   NOSTR_RELAYS="wss://relay1.com wss://relay2.com wss://relay3.com"
+   ```
+3. The wizard interface (coming soon for Start9/Umbrel) will make this graphical
+
+See `env.example` for all available configuration options.
+
+### Bootstrap Liquidity Provider
+
+By default, Lightning.Pub uses a bootstrap liquidity provider that provides initial channel funding as a service credit until you can afford your own channels. Pub compares rates from top LSPs and automatically requests a channel when needed.
+
+You can disable this for full sovereignty via `DISABLE_LIQUIDITY_PROVIDER=true` in `.env`, or re-point to any other Lightning Pub (not just ShockNet's) via `LIQUIDITY_PROVIDER_PUB`.
+
+### Configuration
+
+Copy `env.example` to `.env` and customize settings:
+```bash
+cp env.example .env
+nano .env  # or use your preferred editor
+```
+
+> [!IMPORTANT]
+> Environment variables set in `.env` will override any settings configured via the wizard or stored in the settings database table.
+
+Key settings:
+- `NOSTR_RELAYS`: Custom Nostr relay(s) to use
+- `DISABLE_LIQUIDITY_PROVIDER`: Set to `true` to disable bootstrap liquidity provider (alternatively, set `LIQUIDITY_PROVIDER_PUB=null` or to the nprofile of a preferred Pub instance)
+- `BRIDGE_URL`: Configure which CLINK -> Suggets a LNURL bridge to wallets to use for Lightning Address enrollment (default: `https://shockwallet.app`)
+- `SERVICE_URL`: Your domain URL for enabling LNURL directly on Pub (requires SSL via a reverse-proxy pointing to Pub's port)
+- See `env.example` for complete documentation
 
 Additional docs are WIP at [docs.shock.network](https://docs.shock.network)