The Sovereign
Stack

Why This
Matters Now

In late 2021, a group of builders launched a DAO called Node Star. The goal was simple: use blockchain architecture to decentralize ownership of communication infrastructure. Then 2022 happened. The markets collapsed. The speculative energy evaporated. Most of us who had poured ourselves into Web3 found ourselves staring at the wreckage wondering what, if anything, had been real.

What was real, it turned out, was the question underneath. Not the tokens, not the governance mechanisms, not the smart contracts. The question: what if the internet could belong to everyone?

That question didn't die. It just needed a different answer — and a different starting point. Web4 is the physical infrastructure layer: LoRa radios, mesh networks, cryptographic routing. But the vision of Web3 — decentralized ownership, trustless payments, censorship-resistant data — was never wrong. It was just disconnected from physical reality. Running a decentralized application on a server farm in Virginia is not decentralization. Running it on a mesh network your community owns is a different thing entirely.

This guide is about connecting those two ideas. It's not a beginner's guide to blockchain. It's not a beginner's guide to mesh networking. It assumes you've read the earlier Node Star guides — you understand LoRa, Meshtastic, and Reticulum. Now we're going to talk about what happens when you layer blockchain-based databases, decentralized storage, and peer-to-peer payments on top of that physical infrastructure.

The result is what we call the Sovereign Stack: a complete, community-owned system for communication, data, and value exchange that requires no corporation, no ISP, no bank, and no government permission to operate.

What This Guide Covers — and What It Doesn't

This guide focuses on practical integration: what software to run, how to configure it, and how to make Web3 protocols actually function in an offline-first, mesh-native environment. It does not cover tokenomics, investment advice, or which blockchain "will win." Those questions are outside scope and, frankly, outside the point.

The protocols we'll work with were chosen for one reason: they work when the internet is down, or can be made to work with modest engineering effort. Several well-known blockchain projects — Ethereum mainnet, most NFT infrastructure, centralized exchange rails — are not covered here because they require persistent internet connectivity to function. They belong to Web3. What follows belongs to the Sovereign Stack.

The Architecture —
Web3 Meets Web4

The Sovereign Stack has four layers. Each one is independent — you can run any layer without the others — but they're designed to compose. Build the physical layer first. Layer the data protocols on top. Add payments. Add identity. By the time you've assembled all four, you have something that has never quite existed before: a complete community-owned infrastructure stack that handles communication, storage, money, and identity without a single trusted third party.

The Key Insight: Content Addressing

The internet you grew up with is location-addressed. When you request example.com/file.pdf, you're asking a specific server at a specific address for a file. If that server goes offline, the file is gone. If the server lies to you and returns a different file, you'd have no way to know.

The Sovereign Stack uses content addressing instead. A file's address is derived from its contents — specifically, a cryptographic hash of those contents. The address of a file is literally the fingerprint of the file. This means:

An IPFS hash like QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco is not an address on a server. It's a description of the data itself. Any node that has a copy of that data can serve it to you — including a node on your local mesh network. The file is verified automatically: if someone hands you corrupt data, the hash won't match and you'll know immediately.

This is the architectural key that makes the Sovereign Stack possible. Blockchain ledgers are content-addressed. IPFS files are content-addressed. Bitcoin transactions are verified by content, not by trusting a bank. The whole stack is built on the same underlying idea: cryptographic proof instead of institutional trust.

How the Layers Talk to Each Other

Decentralized Storage
on the Mesh

The most immediately practical piece of the Sovereign Stack is decentralized storage. This doesn't require internet connectivity, doesn't require tokens, and doesn't require any special hardware beyond a gateway node. It gives your mesh community the ability to host files, documentation, maps, and application data in a way that's resilient to any single node going down.

IPFS: The Foundation

IPFS (InterPlanetary File System) is a peer-to-peer protocol for storing and sharing data in a distributed file system. When you add a file to IPFS, it gets chunked, hashed, and distributed. Anyone who has pinned that file can serve it to anyone else who requests it by hash. The requesting party verifies the data automatically.

On a mesh network, IPFS operates as a local cluster: your gateway node and any other nodes running IPFS daemons form a private swarm. Files added to the swarm are available to all nodes on the mesh — even without internet. When internet connectivity is restored at a gateway, the local swarm can optionally sync with the global IPFS network.

Installing IPFS (Kubo) on a Raspberry Pi

# Find the current stable ARM64 release at dist.ipfs.tech, then download.
# Replace VERSION below with the latest tag shown on that page (e.g. v0.33.0).
$ VERSION=v0.33.0   # ← update this before running
$ wget https://dist.ipfs.tech/kubo/${VERSION}/kubo_${VERSION}_linux-arm64.tar.gz
$ tar -xvzf kubo_${VERSION}_linux-arm64.tar.gz
$ cd kubo && sudo bash install.sh

# Initialize your IPFS node
$ ipfs init --profile server

# Configure for local mesh use — limit DHT to client-only (no global routing)
# Note: Routing config keys have evolved across Kubo versions.
# In v0.35+ the preferred approach is to set Routing.Type via the config file.
$ ipfs config --json Routing '{"Type":"dhtclient"}'
$ ipfs config --json Swarm.DisableNatPortMap true

# Start the daemon
$ ipfs daemon --enable-gc
BASH

Creating a Private Mesh IPFS Swarm

By default, IPFS connects to the global public network. For a community mesh deployment you want a private swarm — only nodes that know the swarm key can join. This keeps your mesh content off the public IPFS network while still enabling all the benefits of content-addressed distributed storage within your community.

# Generate a swarm key (do this once on the gateway node)
$ go install github.com/Kubuxu/go-ipfs-swarm-key-gen/ipfs-swarm-key-gen@latest
$ ipfs-swarm-key-gen > ~/.ipfs/swarm.key

# The swarm.key file looks like this:
# /key/swarm/psk/1.0.0/
# /base16/
# a93f8c3...d719a2b

# Copy this swarm.key to every node that should join your mesh swarm
# Nodes without it cannot connect to your private swarm

# Remove default bootstrap peers (public IPFS network)
$ ipfs bootstrap rm --all

# Add your gateway node as the bootstrap peer for all mesh nodes
$ ipfs bootstrap add /ip4/<GATEWAY_IP>/tcp/4001/p2p/<GATEWAY_PEER_ID>
BASH

What to Store on the Mesh

Not everything belongs on an IPFS mesh swarm. LoRa bandwidth is limited — a Meshtastic message maxes out around 240 bytes. The mesh IPFS swarm is for your gateway node and any WiFi-connected secondary nodes, not for direct LoRa transmission of IPFS content. Think of it as a community NAS (network-attached storage) that the mesh can reference, not a protocol running over LoRa radio.

OrbitDB: A Database for the Mesh

IPFS stores static files. OrbitDB extends that into a distributed database — specifically, a set of CRDT (Conflict-free Replicated Data Type) databases that sync automatically across all nodes that hold the same database. It's built entirely on IPFS and libp2p, which means it runs on any IPFS node with no additional infrastructure. As of 2026, OrbitDB is actively maintained and Helia-based integrations (Helia being the newer modular IPFS library) are now the preferred setup for fresh deployments.

For a mesh community, OrbitDB enables applications that would normally require a central server: shared bulletin boards, resource inventories, message logs, event registries. When nodes come online and sync, they catch up automatically. When they're offline, they operate from their local copy.

# Install OrbitDB (requires Node.js)
$ npm install @orbitdb/core helia

# Minimal example: create a shared key-value store
import { createHelia } from 'helia'
import { createOrbitDB } from '@orbitdb/core'

const helia = await createHelia()
const orbitdb = await createOrbitDB({ ipfs: helia })

# Open (or create) a shared database — all nodes using this address share data
const db = await orbitdb.open('mesh-community-board', { type: 'documents' })

# Write a document
await db.put({ _id: 'announcement-001', text: 'Node on 4th + Elm is back online' })

# Read all documents
const all = await db.all()
JS

Filecoin and Arweave: Permanent Storage

IPFS alone doesn't guarantee persistence. A file exists on the IPFS network only as long as at least one node has pinned it. For truly permanent, verifiably preserved data — community archives, legal records, historical documentation — you need a persistence layer with economic incentives for storage providers.

Payments Without
Banks or Cell Towers

Peer-to-peer payments are the most immediately practical piece of the blockchain stack for a mesh community. Not speculative investment — payments. The ability to pay someone $3 for bandwidth without a bank, without a payment processor, without even the internet being up.

Two protocols deserve attention here: the Lightning Network (Layer 2 Bitcoin) for fast, low-fee micropayments; and Monero for privacy-preserving transactions where anonymity matters. Each has different trade-offs for offline and mesh use.

Lightning Network — The Mesh-Compatible Payment Rail

Bitcoin's base layer is too slow and too expensive for mesh micropayments. The Lightning Network solves this by creating payment channels: two parties lock funds into an on-chain multisig, then exchange signed payment transactions off-chain at zero fee and near-instant speed. They only need to broadcast to the Bitcoin blockchain when opening or closing a channel.

The critical property for mesh use: once a Lightning channel is open, payments within that channel require no blockchain access and no internet connectivity. Two gateway nodes can exchange thousands of micropayments over LoRa links with no internet, settling on-chain when connectivity is restored.

Running a Lightning Node on a Raspberry Pi

The recommended stack for a gateway node is Bitcoin Core (full node or pruned) + LND (Lightning Network Daemon) or Core Lightning (CLN). This runs comfortably on a Raspberry Pi 4 with a 1TB SSD.

# Install LND on Raspberry Pi (ARM64)
# Check github.com/lightningnetwork/lnd/releases for the current stable ARM64 build.
# Replace VERSION below with the latest release tag before running.
$ VERSION=v0.18.5-beta   # ← update to the current release
$ wget https://github.com/lightningnetwork/lnd/releases/download/${VERSION}/lnd-linux-arm64-${VERSION}.tar.gz
$ tar -xvf lnd-linux-arm64-${VERSION}.tar.gz
$ sudo install -m 0755 -o root -g root lnd-linux-arm64-${VERSION}/lnd /usr/local/bin/lnd
$ sudo install -m 0755 -o root -g root lnd-linux-arm64-${VERSION}/lncli /usr/local/bin/lncli

# Minimal lnd.conf for a gateway node
# Located at ~/.lnd/lnd.conf
[Application Options]
alias=YourNodeName
color=#a78bfa

[Bitcoin]
bitcoin.active=1
bitcoin.mainnet=1
bitcoin.node=bitcoind

[Bitcoind]
bitcoind.rpchost=localhost
bitcoind.rpcuser=yourrpcuser
bitcoind.rpcpass=yourrpcpassword
CONF

Use Cases for Mesh Lightning Payments

Monero — Privacy-Preserving Transactions

Bitcoin and Lightning transactions are pseudonymous, not anonymous. With enough chain analysis, payment flows can be traced. For a community that values genuine privacy — activists, journalists, communities in contested political environments — Monero provides cryptographically enforced privacy at the protocol level.

Monero uses ring signatures, stealth addresses, and RingCT (confidential transactions) to make transaction amounts, senders, and recipients unlinkable by default. No opt-in. No mixing service. No extra steps. Private by design.

The practical challenge for mesh use is that Monero's full node is heavier than Bitcoin's for a Raspberry Pi. The recommended approach for mesh deployments is to run a remote node strategy during internet access periods, and use Feather Wallet for watch-only balance monitoring and offline transaction signing.

Offline Signing Workflow with Feather Wallet

Feather supports a cold-signing workflow well-suited to mesh deployments: the gateway Pi runs a watch-only wallet (primary address + view key, no spend key) that tracks incoming funds. When you need to spend, you construct an unsigned transaction on the Pi, move it to an air-gapped device for signing, then broadcast it the next time internet is available.

Lightning Alternatives: Core Lightning and I2P

LND is the most widely deployed Lightning implementation but not the only one. Core Lightning (CLN), formerly c-lightning, is a lighter-weight, plugin-based implementation that uses noticeably less RAM on constrained hardware — a real advantage on a Pi 4 (4GB) running multiple services simultaneously. CLN's plugin architecture also makes it easier to extend with custom mesh-specific payment logic without touching core code.

For network-layer anonymity, LND's native Tor support (covered in OpSec) is the standard choice. I2P is an alternative with different traffic analysis resistance properties than Tor — some operators layer LND over I2P for additional anonymity, though ecosystem support is more limited. If Tor is unavailable or blocked in your operating environment, I2P is worth evaluating.

Cryptographic Identity,
Unified

Identity is the quietest and most important layer of the Sovereign Stack. Every other layer depends on it. Payments require knowing who you're paying. Storage access control requires knowing who has permission. Mesh routing requires knowing who to trust. In the legacy internet, identity is delegated to institutions: Google, Apple, your phone carrier. In the Sovereign Stack, identity is a keypair you generate yourself.

Reticulum Identity — The Native Layer

If you've worked with Reticulum, you already have a native mesh identity. Every Reticulum destination is derived from a public key. Your Reticulum address is not a username registered with a server — it's a hash of a public key that lives in a file on your device. Nobody issued it to you. Nobody can revoke it. Nobody can impersonate you without your private key.

# View your Reticulum identity
$ rnid --list

  Identity [12f4a3...]  Created: 2025-11-15
  Destination [8e2c1b...]  Type: single
  Name: <yourname>.mesh

# Export your public key for distribution
$ rnid --export 12f4a3...

# This is what you share with others for encrypted messaging
# The hash of this key IS your address — unforgeable, unrevokable
BASH

Decentralized Identifiers (DIDs)

Reticulum identity is powerful within the mesh but doesn't bridge well to Web3 contexts — dApps, smart contracts, or cross-network reputation systems that expect a standard format. This is where DIDs (Decentralized Identifiers) come in.

DIDs are a W3C standard for self-sovereign identity. A DID looks like a URI: did:key:z6Mkf... or did:web:yournode.mesh. The DID document it points to contains your public keys, service endpoints, and verification methods — all cryptographically verifiable, all under your control. No registration. No central authority.

For mesh-native deployments, did:key is the right choice. A did:key DID encodes the public key directly in the identifier — no blockchain, no server, no lookup required. It resolves entirely offline. The identifier is the key. Combined with a Reticulum address, you get a mesh identity that works across protocols.

Bridging Reticulum Identity to DID:Key

Reticulum identities are Ed25519 keypairs — the same curve used by the did:key method. In principle, your Reticulum public key can be expressed as a did:key identifier, making it resolvable by any DID-aware system without a central registry.

Tooling for this bridge is still maturing. The practical path today is to generate a separate Ed25519 keypair using a tool like did-cli (available via npm: npm install -g @digitalcredentials/did-cli) and register it independently, then publish both your Reticulum destination hash and your DID together so others can associate them. Cross-signing support between Reticulum and W3C DID systems is an active area of development in the Reticulum community.

# Generate a did:key using the DID CLI (npm-based, not pip)
$ npm install -g @digitalcredentials/did-cli
$ did generate --method key

  did:key:z6Mkf8pFxYBuJfCMGSC3NWkJNqR4sXtK7mEfSy3PjzB9oVkH

# Publish this DID alongside your Reticulum destination hash.
# Full keypair export from rnid for cross-signing is not yet supported
# in stable Reticulum tooling — check reticulum.network for updates.
BASH

ENS Names — Human-Readable Addresses

Cryptographic identifiers are unambiguous but not memorable. ENS (Ethereum Name Service) maps human-readable names like yourname.eth to cryptographic addresses — Ethereum addresses, but also IPFS content hashes, Reticulum addresses, or any other identifier you want to associate.

The catch: ENS resolution requires an Ethereum node or RPC endpoint, which means internet connectivity. For mesh use, the practical approach is to cache ENS records locally during internet-available periods, using your gateway node as a local ENS resolver that serves cached records to mesh clients when offline.

# Helios light client — syncs Ethereum state with no full node
$ cargo install helios
$ helios ethereum --network mainnet --rpc-port 8545 \
    --checkpoint 0x...  # latest finalized checkpoint
BASH

Governance &
Economic Incentives

The question of how to incentivize node operators — especially high-value relay nodes on rooftops and hilltops — is one of the oldest problems in community mesh networking. Voluntarism works in the beginning. It doesn't scale. Germany's Freifunk network runs on social norms; your city might not have that culture yet. Economic incentives are more reliable than goodwill.

Smart contracts offer a technically elegant solution. A contract on a blockchain can trustlessly distribute rewards to node operators who prove their uptime, forward traffic, or contribute storage. No central authority manages the payments. No one can steal the pot. The rules are code.

The Helium Cautionary Tale

Before getting into how to do this well, it's worth examining how it was done badly. Helium was a blockchain-based LoRa network with token incentives for node operators. At its peak, it had hundreds of thousands of nodes. It seemed like exactly the model we're describing.

What went wrong:

A Better Model: Community Treasury Contracts

Rather than issuing a new token, a community mesh can use a simple treasury contract: a multisig wallet or DAO contract that holds community funds (in Bitcoin, stablecoins, or whatever the community agrees on) and distributes them based on on-chain proofs of service. No speculative token. No mining. Just: provide service, get paid.

Proof-of-Coverage on a Shoestring

The expensive part of Helium's model was its elaborate Proof-of-Coverage system. For a community mesh, a simpler approach works: cryptographically signed uptime beacons.

Each relay node periodically broadcasts a signed beacon over LoRa. Other nodes that receive it sign and timestamp the receipt. These receipts accumulate on the local IPFS node and are periodically submitted (when internet is available) as uptime proofs to the treasury contract. A node that receives beacon confirmations from multiple neighbors is provably online and covering useful geography.

# Example: generating a signed uptime beacon (Python pseudo-implementation)
import time, hashlib
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey

private_key = Ed25519PrivateKey.generate()

def sign_beacon(node_id, timestamp):
    payload = f"{node_id}:{timestamp}:{hashlib.sha256(str(timestamp).encode()).hexdigest()[:8]}"
    signature = private_key.sign(payload.encode())
    return { "payload": payload, "sig": signature.hex(), "pubkey": ... }

# Broadcast this over Reticulum or Meshtastic periodically
# Receiving nodes sign and store the receipt in their local IPFS node
# Aggregated receipts = verifiable uptime proof
PYTHON

DAO Tooling for Mesh Governance

If your community wants formal on-chain governance — voting on protocol changes, treasury disbursements, node membership — several lean DAO frameworks can be deployed on low-cost EVM chains (Gnosis Chain, Polygon) rather than expensive Ethereum mainnet.

What a Minimal Governance Setup Looks Like

Here's a concrete example: a 5-person founding team sets up a 3-of-5 Safe multisig on Gnosis Chain (low gas costs). They create a Snapshot space tied to their community's ENS name. When a node operator requests reimbursement for equipment, any member posts a proposal. After 48 hours and a passing vote, three key-holders sign the Safe transaction and funds are released.

Sample Snapshot Proposal Structure

// Snapshot proposal (authored offline, published when internet available)
// Stored on IPFS, signed with your wallet — no gas required
{
  "space": "nodestar-socal.eth",
  "type": "single-choice",
  "title": "Fund rooftop relay node at 4th + Elm — $120 equipment reimbursement",
  "body": "Operator @meshnode-7 installed a solar-powered relay node covering the Eastside gap. Requesting reimbursement for verified hardware costs.",
  "choices": ["Approve", "Reject", "Request more info"],
  "start": 1740000000,      // Unix timestamp
  "end": 1740172800,        // 48 hours later
  "snapshot": 12345678,     // Block number for voting power snapshot
  "discussion": "https://forum.nodestar.net/t/eastside-relay"
}
JSON

Safe Multisig — Initial Setup

# Deploy a Safe on Gnosis Chain (low fees, EVM compatible)
# Via safe.global UI or safe-cli tool

# 1. Connect 5 founding member wallets
# 2. Set threshold: 3 of 5 required signatures
# 3. Fund the Safe with community treasury (xDAI, USDC, or BTC via bridge)
# 4. Record Safe address — add to ENS records as "multisig" text field

# To execute a passed Snapshot vote:
$ safe-cli --safe-address 0xYourSafe... \
    --private-key $SIGNER_KEY \
    send-eth --to 0xRecipient... --value 120

# Requires 2 more co-signers to also submit — threshold enforced on-chain
BASH

The Minimum Viable
Sovereign Stack

Everything so far has been architecture. This section is a concrete bill of materials and setup sequence for the smallest sovereign stack that's actually useful. Not the full vision — the minimum version that works today, with real hardware and real software, for a real community.

Hardware Requirements

Software Setup Sequence

$ sudo apt update && sudo apt upgrade -y
$ sudo apt install -y git curl wget python3 python3-pip nodejs npm \
    build-essential libssl-dev pkg-config
# Install Rust (needed for Helios and some IPFS tools)
$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
BASH

$ pip install rns rnodeconf --break-system-packages
# Flash your WisBlock/RNode (interactive — plug in board when prompted)
$ rnodeconf --autoinstall
# Add to ~/.reticulum/config as a LoRa interface
BASH

# ~/.bitcoin/bitcoin.conf
prune=550
txindex=0
daemon=1
rpcuser=meshnode
rpcpassword=<strong-random-password>
rpcbind=127.0.0.1
rpcallowip=127.0.0.1
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333
CONF

$ lncli create   # creates wallet, save seed phrase OFFLINE
$ lncli newaddress p2wkh   # get deposit address
# Fund it, then open a channel
$ lncli connect <NODE_PUBKEY>@<IP>:9735
$ lncli openchannel --node_key <NODE_PUBKEY> --local_amt 100000
BASH

What You've Built

At the end of this setup, your gateway node is running six services that interlock. Here's how they relate — which processes depend on which, what ports they use, and what remains functional when internet goes down:

Quick-Start Checklist

Print this or screenshot it. Work through it top to bottom — each layer depends on the ones above it being stable before you proceed.

Security &
OpSec

Adding a Lightning node and IPFS storage to your mesh gateway materially increases your attack surface. A compromised gateway node could lose funds (Lightning channels), expose community data (IPFS), or allow impersonation (key theft). The security fundamentals here are not optional.

Key Management — The Non-Negotiable Part

Your LND wallet seed is 24 words that control every satoshi in your Lightning channels. Your Reticulum identity keys control your mesh address and any signed attestations. Your DID private key controls your cross-network identity. These must never exist only on the Pi.

# Add to lnd.conf — enables the watchtower and client in one node
[Watchtower]
watchtower.active=true

[WatchtowerClient]
wtclient.active=true
# Optionally add a remote watchtower for redundancy:
# wtclient.add-tower=pubkey@host:port

# Verify watchtower is running after restart
$ lncli tower info
$ lncli wtclient towers

Network Hardening

Your gateway Pi should not be reachable from the public internet unless you explicitly need it to be. Lightning peers connect on port 9735 — this should only be reachable from trusted peers, not the open internet, unless you are intentionally acting as a public Lightning routing node (which is a different operational profile).

# UFW firewall setup for a gateway node
$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing
$ sudo ufw allow from 192.168.0.0/24 to any port 22    # SSH local only
$ sudo ufw allow from 192.168.0.0/24 to any port 8080  # IPFS gateway local only
$ sudo ufw allow from 192.168.0.0/24 to any port 8545  # ENS resolver local only
$ sudo ufw allow 9735                                   # LN peers (public)
$ sudo ufw allow 4001                                   # IPFS swarm
$ sudo ufw enable
BASH

Exposing the IPFS Gateway Safely Over the Mesh

The IPFS HTTP gateway (port 8080) lets any browser or app fetch content by hash — useful for mesh nodes that want to pull maps, documents, or app data from the gateway without running a full IPFS daemon. The risk is exposing this to the broader internet. The solution is to proxy it through Nginx with basic authentication, binding it only to your local mesh network interface.

# Install Nginx
$ sudo apt install nginx apache2-utils -y

# Create a password file for gateway auth
$ sudo htpasswd -c /etc/nginx/.htpasswd meshuser

# /etc/nginx/sites-available/ipfs-gateway
server {
    listen 8888;               # Mesh-facing port (not 8080)
    server_name _;

    auth_basic           "Mesh IPFS Gateway";
    auth_basic_user_file /etc/nginx/.htpasswd;

    # Only allow requests from your local mesh subnet
    allow 192.168.0.0/24;
    deny  all;

    location /ipfs/ {
        proxy_pass         http://127.0.0.1:8080;
        proxy_set_header   Host $host;
        # Optional: cache aggressively — content-addressed files never change
        proxy_cache_valid  200 7d;
    }
}
NGINX

Threat Model: Know What You're Protecting Against

The Tor Layer

LND has native Tor support. Running your Lightning node over Tor hides your IP address from channel peers and any observer monitoring the Lightning gossip network. For communities in politically sensitive contexts, this is not optional.

# Enable Tor for LND in lnd.conf
[Tor]
tor.active=true
tor.socks=127.0.0.1:9050
tor.streamisolation=true
tor.v3=true

# Your node will get a .onion address
# Peers connect to it without knowing your IP
# IPFS can also be configured to use Tor for internet-facing connections
CONF

Appendix —
Tools, Links & Reference

Software Stack at a Glance

Hardware Bill of Materials

Further Reading