Sovereign P2P / Mesh / Self-Hosted Stack Guide

Layered, adversarially-audited blueprint for decentralized comms, storage, and value.

1. Design Goals & Filters

Every component in this guide is selected and ranked under the same strict constraints:

  • No identity lock-in – no mandatory phone numbers, emails, or KYC for core tools; preference for pseudonymous or identity-less operation.
  • Self-hostable & forkable – free/open-source, runnable on your own hardware; you can exit to your own infrastructure without permission.
  • Offline-first / mesh-compatible – LAN, BLE, Wi-Fi mesh, and LoRa must be viable transport layers; the internet is an optimization, not a requirement.
  • Minimal, composable protocols – fewer moving parts, simple mental models, well-understood cryptography and networking.
Tag legend:
Core Stack – candidates to actually deploy Primitive Map – study / pattern extraction R&D – experimental, not daily-driver Enemy / Intel – synthetic stack reconnaissance

2. Layered Architecture

The stack is divided into layers that can be combined or swapped as needed: communication, mesh/network substrate, storage & services, value, and identity discipline.

2.1 Human Communication Layer

2.1.1 Local, no-infrastructure chat (phones only)

Bitchat Core Stack

  • Offline, end-to-end encrypted messenger over Bluetooth Low Energy (BLE) mesh; no internet, SIM, servers, or phone numbers required.
  • Devices relay messages, extending range hop-by-hop across phones.
  • Dual transport:
    • Local: BLE mesh for nearby chat channels.
    • Online: Nostr-based geohash channels for regional/global chat when internet is available.
  • “Panic mode” shortcut to wipe local data quickly.
  • Open-source and permissively licensed; reference implementation for BLE mesh + Nostr bridging.

Briar Core Stack

  • Android messenger that uses Tor, Bluetooth, and Wi-Fi Direct with no central server.
  • Store-and-forward: messages sync whenever peers meet by any supported transport.
  • Designed for censorship-resistant, offline-friendly use in high-risk environments.
Role: Bitchat and Briar form a human-scale mesh: fast, local, no-infrastructure chatter (Bitchat), plus slower, persistent sync across time and distance (Briar).

2.1.2 Internet-present, high-privacy messaging

SimpleX Chat Core Stack

  • Messaging network with no user identifiers at the protocol level; contacts and groups exist only on user devices.
  • Uses brokered message queues designed so that brokers never see stable user IDs or social graphs.
  • Open-source, independently audited, and hardened against state-level demands for decryption and metadata.
  • Multi-platform (mobile & desktop); suitable as a daily driver when the internet is available but untrusted.
Role: primary “internet-up, hostile regime” messenger, offering strong privacy without phone numbers or central identity registries.

2.1.3 Federated & community comms

Matrix (self-hosted homeserver) Core Stack

  • Open protocol for federated chat, VoIP, and bridging to many platforms (IRC, XMPP, etc.).
  • Run your own homeserver (Synapse, Dendrite, etc.) under your own domain.
  • Ideal for persistent community rooms, cross-device chat, and integrations with bots/gateways.

Jitsi (self-hosted) Core Stack

  • Open-source video/voice conferencing system; self-hosted to avoid relying on public instances.
  • Integrates well with Matrix and other identity systems under your control.
Role: together, Matrix and Jitsi implement the “community intranet” for coordination, with rooms that can also receive events from mesh/LoRa gateways.

2.2 Mesh & Network Substrate

The network substrate operates in three physical regimes: BLE mesh, Wi-Fi/router mesh, and LoRa mesh.

2.2.1 BLE mesh

Handled primarily by Bitchat as described above, for dense, short-range device-to-device messaging without infrastructure.

2.2.2 Wi-Fi & router mesh

Awesome Mesh Primitive Map

  • Curated list of mesh networking documentation, routing protocols (Babel, BATMAN, OLSR, etc.), and software stacks.
  • Includes community mesh firmware like LibreMesh, QMP, and more.
Role: use Awesome Mesh to pick routing protocols and firmware for Wi-Fi mesh backbones that interconnect homes, nodes, and local servers.

2.2.3 LoRa mesh – Meshtastic

Meshtastic Core Stack

  • Open-source project for turning inexpensive LoRa radios into a long-range, low-bandwidth text and telemetry mesh.
  • Devices relay encrypted messages; phones/computers connect via Bluetooth, Wi-Fi, or USB.
  • Bridges available for MQTT, mapping, dashboards, and integration with home automation or chat servers.
Role: slow but resilient signaling channel for safety check-ins, alerts, coarse location, and tiny commands – especially where infrastructure is unreliable or absent.

2.3 Storage & Services Layer

2.3.1 Self-hosted services catalog

Awesome Self-Hosted Primitive Map

  • Comprehensive list of self-hostable network services and web apps, categorized by function (analytics, VPN, chat, mail, etc.).
  • Backed by a machine-readable data repository and third-party explorers for filtering.
Role: catalog for components like VPN/WireGuard managers, Git hosting, monitoring, and other services once the comms substrate is solid.

2.3.2 File sync & replication

Syncthing Core Stack

  • Continuous, peer-to-peer file synchronization between devices, with encrypted communications and no central server required.
  • Works across LAN, internet, or VPN; devices discover each other and sync only changed blocks.
Role: replicate critical documents, configuration, and small databases across laptops and servers, forming a resilient “ops folder” layer.

2.3.3 Content-addressed storage

IPFS Core Stack

  • Content-addressed file system: data addressed and verified by cryptographic hashes (CIDs), using a DHT and block exchange.
  • Supports deduplication and verifiable integrity across local and wide-area networks.
  • Ecosystem “awesome” list catalogs tools, GUIs, and pinning services for IPFS.
Adversarial stance: use IPFS as a local and community protocol (with self-run nodes and pinning clusters), not as a dependency on third-party gateways or public pinning for anything sensitive.

2.4 Bitcoin & Value Layer

Bitcoin + Lightning Nodes Core Stack

  • Self-run Bitcoin full nodes on community hardware for monetary sovereignty.
  • Lightning nodes for fast payments when connectivity is sufficient, enabling local markets and rapid settlement.

LNMesh R&D

  • Research and prototypes showing Lightning Network payments routed over ad-hoc wireless mesh networks (BLE/Wi-Fi) without continuous internet connectivity.
  • Simulations and experiments indicate successful offline payments are possible with careful channel assignment and sufficient liquidity.
Role: LNMesh is a design blueprint, not a finished product – a source of patterns for integrating mesh and Bitcoin, rather than a plug-and-play wallet.

2.5 Identity & Metadata Discipline

Identity and metadata discipline is a constraint applied to every layer, not a single tool.

  • Prefer messengers and protocols with:
    • No phone numbers or global identifiers (SimpleX, Bitchat).
    • Local, user-held keys and configuration.
  • Treat formal SSI/DID systems (national eIDs, enterprise “self-sovereign identity” infrastructure) as Enemy / Intel – maps of prospective control systems to route around, not foundations for core identity.

3. Master Indexes & How to Mine Them

3.1 P2P Fundamentals

Awesome P2P (mafintosh) Primitive Map

  • Concise list of P2P protocols, libraries, and resources: BitTorrent, DHTs, replication systems, etc.
  • Value lies in the conceptual patterns (swarming, discovery, log replication) rather than in directly deploying the listed projects.

3.2 Mesh Networking

Awesome Mesh (moarpepes) Primitive Map

  • Documentation, routing protocols, firmware, and applications for mesh networking across routers, desktops, and mobiles.
  • Use to pick a concrete routing protocol and firmware combination for a given community mesh.

3.3 Self-Hosting

Awesome Self-Hosted Primitive Map

  • Giant function-sorted catalog of self-hostable services, with machine-readable metadata.
  • Act as the marketplace of options for VPN, monitoring, Git hosting, and other services once the communications substrate is in place.

3.4 Decentralized Apps

Awesome Decentralized (croqaz) Primitive Map

  • Broad list of decentralized apps and tools, including Bitchat, SimpleX, Briar, and others.
  • Use as a discovery index: manually vet each candidate against the filters in Section 1 before trusting or deploying.

4. Deployment Recipes

4.1 Personal / Small-Cell Kit (No Servers)

Goal: a small group can communicate under surveillance and intermittent or absent internet with only their phones and a few portable devices.

  • On each phone:
    • Bitchat for immediate local BLE mesh chat without accounts.
    • Briar (Android) for Tor/Bluetooth/Wi-Fi Direct store-and-forward messaging.
    • SimpleX Chat for high-privacy messaging when internet connectivity exists.
  • Optional: carry a small LoRa node running Meshtastic, paired to a phone, to extend signaling range beyond BLE/Wi-Fi coverage.

4.2 Home / Neighborhood Node

Goal: an always-on local box acts as the neighborhood backbone for communications and basic services.

  • Deploy on a mini-PC, Raspberry Pi, or repurposed laptop:
    • Syncthing to sync important files with trusted devices.
    • A self-hosted Matrix homeserver for local chat rooms and bot/bridge integration.
    • Jitsi for private video/voice calls within the group.
    • A small Meshtastic gateway, bridged into Matrix rooms via MQTT or dedicated bridge software.
    • WireGuard (and optionally Tor) to provide secure remote access and link multiple neighborhood nodes.

4.3 Community Mesh + Bitcoin Overlay (R&D-Heavy)

Goal: multiple neighborhoods form a sovereign micro-network with resilient communications and local value flow.

  • Use Awesome Mesh to select routing protocols and firmware (e.g., LibreMesh on OpenWrt routers), then deploy a basic Wi-Fi mesh backbone.
  • On backbone nodes:
    • Run Matrix, Jitsi, Syncthing, and IPFS.
    • Run Bitcoin full nodes and Lightning nodes for local markets and payments.
  • Experiment with LNMesh patterns:
    • Route LN messages over the Wi-Fi mesh and (where possible) via BLE; rely on gateways to open channels and settle when the wider internet becomes reachable.
    • Fall back to vouchers and IOUs when full LN semantics are overkill or fragile under particular conditions.

5. Ongoing Audit Checklist

Apply this checklist to every tool, update, or new component before it enters the core stack.

  1. Self-hosting: Can it run entirely on hardware you control with no external accounts?
  2. Identity: Does it require a phone number, email, or government ID? If so, is that strictly optional and isolated?
  3. Offline capability: Can it function (even partially) over LAN/mesh with no internet?
  4. Control plane: Who operates the default servers (relays, brokers, gateways)? Can you self-host or swap them out without breaking the protocol?
  5. Metadata exposure: Under a global passive adversary, what metadata leaks (timing, size, contact graph)?
  6. Deplatforming resilience: If app stores ban it tomorrow, can you still build, sideload, and distribute it?
  7. Alignment: Does this tool move you toward centralized SSI / digital-ID / CBDC infrastructure, or away from it?
Tools that fail multiple checks should be downgraded to R&D or Enemy / Intel, not integrated into the Core Stack.