A free, open-source chat and peer-to-peer file transfer app for Windows, macOS, Linux + Android — with working web chat, browser transfer, and a CLI for scripts and servers. Built on Rust, Tauri 2, iroh QUIC, iroh-blobs, and BLAKE3.
◆ no upload step ◆ no account ◆ no artificial file-size cap ◆ no telemetry ◆ no cloud bucket ◆
Download · Website · Lightning Chat · AUDIT.md · Roadmap · Changelog · Security
In 30 seconds. Lightning P2P sends a file by handing the receiver a tiny ticket (NodeId + content hash). The receiver pulls the bytes directly from the sender's device over an encrypted iroh QUIC connection — and the receiver can be a browser tab: the same Rust engine runs in-page as WebAssembly, so the other side installs nothing. No upload step. No cloud bucket. BLAKE3 verifies every chunk as it lands. When NAT blocks the direct path, iroh relay carries the encrypted frames — still no plaintext on any server.
| 🚀 Direct, not uploaded | Bytes stream peer-to-peer over QUIC. No cloud bucket, no upload wait, no retention. |
| 🌍 Receive in any browser | The other side installs nothing — your link runs the same Rust engine in their tab as WebAssembly, BLAKE3-verified. |
| 🔒 Verified every chunk | iroh-blobs checks BLAKE3 as data lands. The receiver never has to trust the path. |
| 🌐 NAT-traversing | Direct-first; iroh relay carries encrypted frames when the direct path is blocked. Still no plaintext on any server. |
| 📦 No account, no cap | The ticket is the only credential. No sign-up, no artificial file-size limit, no telemetry. |
| 🖥️ Everywhere | Windows, macOS, Linux, Android — plus a scriptable CLI. One Rust engine behind all of them. |
| ⚡ Tuned for throughput | Six speed modes with BBR congestion control, jumbo-frame probing, and parallel swarm receive. |
| 💬 Lightning Chat | Account-free signed rooms, encrypted direct messages, private groups, media, voice notes, trust QR, and native Bluetooth mesh on Windows and Android. |
# The whole thing, from a terminal:
lightning-p2p-cli send report.pdf # → prints a ticket to stdout
lightning-p2p-cli receive "fd2:…" -o . # → BLAKE3-verified into ./Lightning Chat is a complete communication surface inside Lightning P2P, with its identity and message state isolated from the file-transfer engine. Open the web app immediately, or install the native app for nearby Bluetooth mesh conversations.
| Experience | What works |
|---|---|
| Web | Signed location rooms, encrypted direct messages, nickname identity, reconnect handling, favorites, blocking, and emergency wipe |
| Windows + Android | Everything on web, plus nearby public chat, authenticated private chat, multi-hop forwarding, private groups, media, voice notes, file attachments, delivery state, and trust QR verification |
| Network resilience | Decentralized relay rooms for internet reach; Bluetooth mesh for nearby links; direct Lightning P2P conversations when peers are reachable |
| Privacy controls | Separate chat identity, trust-on-first-use pinning, per-message authenticated encryption, local storage, block/favorite controls, and one-action local wipe |
The nearby wire format follows the deployed mesh protocol: signed announcements and public messages, Noise XX private sessions, bounded fragmentation, gossip synchronization, courier envelopes, group epoch rotation, and replay-safe transport nonces. Chat attachments are intentionally capped; use Lightning Transfer for large files.
The oldest objection to P2P transfer: "but they'd have to install it too." Not anymore.
you (app / CLI) them (any browser)
────────────── ──────────────────
drop files → share the /receive link → open link → "Receive in this browser"
↳ the same Rust engine loads as WASM
↳ pulls chunks straight from you
↳ BLAKE3-verifies every byte in the tab
↳ Save — done. Nothing installed.
- Not a JS reimplementation — the identical
iroh+iroh-blobscore, compiled to WebAssembly (web-receiver/). - No server in the middle — the ticket stays in the URL fragment (never sent to the site), the bytes go peer → tab over the iroh relay.
- Honest limits — browsers can't hole-punch (relay-only) and files live in tab memory (use the app past ~2 GB). The tab must stay open while sharing.
| ✓ Best fit | ✗ Not for |
|---|---|
| Moving large builds, databases, media between desktops | Browser shares beyond ~2 GB (tabs are memory-bound; the app streams from disk without limits) |
| Desktop ↔ Android sideload testing | iOS (planned, not shipped) |
| Sharing without cloud accounts, upload caps, or hosted retention | AirDrop protocol compatibility |
| Open-source workflows that need inspectable artifacts + checksums | Phone-to-phone NFC writing (NFC receive only) |
| Honest benchmark methodology with committed evidence | "Fastest in the world" marketing claims |
Stable: v0.4.6. Experimental: v0.9.9 (Lightning Chat on web and native apps, plus BBR congestion control, Warp mode, swarm receive, and ticket pre-warming).
| Platform | Asset | Channel | Best for |
|---|---|---|---|
| Windows | LightningP2P-win-Setup.exe |
Stable | Most users · one-click Velopack |
| Windows | LightningP2PSetup.exe |
Stable | Classic NSIS |
| Windows | LightningP2P.msi |
Stable | Policy-managed deployments |
| macOS | LightningP2P-macos-universal.dmg |
Beta v0.9.9 | 10.15+ · Intel + Apple Silicon · unsigned: right-click → Open |
| Linux | LightningP2P-linux-x86_64.AppImage |
Beta v0.9.9 | Portable AppImage · .deb / .rpm also published |
| Android | LightningP2P-android-latest.apk |
Beta v0.9.9 | Android 10+ sideload · Lightning Chat + Bluetooth mesh included |
| CLI | lightning-p2p-cli |
Beta v0.9.9 | send <file> prints a ticket to stdout · Win/mac/Linux tarballs |
| Browser | lightning-p2p.netlify.app/receive | Public beta | Receiving only — nothing to install, the sender's link is enough |
| Lightning Chat | Open web chat | Beta v0.9.9 | Signed web rooms · encrypted DMs · native nearby chat |
| Experimental | Release v0.9.9 | Pre-release | Lightning Chat · BBR · Warp · swarm receive |
# The CLI in one breath: share a file, pipe the ticket anywhere.
lightning-p2p-cli send big.iso | qrencode -t ansiutf8 # or just copy it
lightning-p2p-cli receive "fd2:..." -o ~/Downloads◆ Verify your install before you trust it (click to expand)
# Windows — checksums and Authenticode
powershell -ExecutionPolicy Bypass -File .\scripts\verify-release.ps1 `
-Installer .\LightningP2P-win-Setup.exe `
-Checksums .\SHA256SUMS.txt
# Android — file hash + signer certificate
(Get-FileHash .\LightningP2P-android-latest.apk -Algorithm SHA256).Hash
Get-Content .\SHA256SUMS-android.txt | Select-String "LightningP2P-android-latest.apk"
apksigner verify --print-certs --verbose .\LightningP2P-android-latest.apkThe signed Android APK's signer certificate fingerprint:
5F:A0:D6:63:46:FF:9C:91:1B:18:D1:2A:5F:77:F1:F0:9B:2D:E2:A7:69:A0:97:68:6C:FC:FA:43:BD:86:29:16
Full trust guide: docs/download-trust.md.
The animated walkthrough near the top follows the complete handoff: stage a file, share the ticket, connect the receiver, and finish with BLAKE3-verified bytes. This static view summarizes the guarantees the app keeps visible throughout that flow.
Direct first, verified end to end. Relay is the encrypted fallback, not a cloud upload.
flowchart LR
subgraph Sender [Sender · native app]
F[files on disk] --> I[iroh-blobs<br/>add + hash]
I --> T[BlobTicket<br/>NodeId + hash]
end
subgraph Path [encrypted iroh QUIC · direct → relay]
D{{direct route<br/>signal-green}}
R{{relay fallback<br/>NAT-traversal hop}}
end
subgraph Receiver [Receiver · native app]
G[iroh-blobs<br/>download] --> V[BLAKE3<br/>verify per chunk] --> O[destination dir]
end
T -.QR / link / paste.-> G
Sender --> D --> Receiver
Sender --> R --> Receiver
classDef sender fill:#08120f,stroke:#7ddf9c,color:#7ddf9c,stroke-width:1.5px
classDef receiver fill:#08120f,stroke:#7ddf9c,color:#7ddf9c,stroke-width:1.5px
classDef path fill:#050706,stroke:#f0c76b,color:#f0c76b,stroke-width:1px
class Sender sender
class Receiver receiver
class Path path
- Sender picks files / folders / an Android share-sheet item.
- Rust engine imports content into the local iroh-blobs store.
- A receive ticket is generated (
NodeId + content hash + format). - Receiver opens a QR, HTTPS handoff link, deep link, or pastes the raw ticket.
- iroh dials direct QUIC; falls back to relay-assisted route when NAT blocks the path.
- iroh-blobs streams BLAKE3-verified bytes to the destination.
Handoff URLs use /receive#t=<ticket> — the ticket lives in the URL fragment, so it never reaches the website server.
Six session-level transfer modes. Each swaps a complete transport profile: congestion controller, QUIC send/recv/stream windows, initial congestion window, MTU-discovery ceiling, max streams, keepalive, import concurrency, idle timeout, UI emit cadence. Persists across launches; node restarts on change (deferred if a transfer is in flight).
| Mode | Engine | Parallelism | Emit | Conn win | Stream win | Streams | Init cwnd | MTU probe | Default for |
|---|---|---|---|---|---|---|---|---|---|
| Battery Safe | CUBIC | 8 | 250 ms | 64 MB | 16 MB | 256 | 14.7 KB | 1452 | Android |
| Standard | CUBIC | 64 | 100 ms | 256 MB | 64 MB | 1024 | 14.7 KB | 1452 | Desktop |
| Fast | BBR | 128 | 100 ms | 256 MB | 64 MB | 1024 | 256 KB | 1452 | — |
| Extreme | BBR | 128 | 200 ms | 512 MB | 128 MB | 2048 | 1 MB | 8952 | — |
| LAN Beast | BBR | 128 | 200 ms | 1024 MB | 256 MB | 4096 | 4 MB | 8952 | — |
| Warp | BBR | 128 | 200 ms | 2048 MB | 512 MB | 8192 | 8 MB | 8952 | — |
Why BBR matters: quinn (iroh's QUIC engine) defaults to loss-based CUBIC, which halves its window on packet loss — devastating on lossy Wi-Fi and high-bandwidth paths. Upstream iroh measured CUBIC up to ~30× slower than BBR on the same LAN path (n0-computer/iroh#4286). Fast and above run BBR; Standard keeps CUBIC so the default behavior stays unchanged. MTU probing above 1452 targets jumbo-frame LANs — quinn binary-searches the path and black-hole detection recovers safely on networks that can't carry large datagrams.
Swarm receive experimental — folder transfers normally fetch files one at a time over a single stream, paying a round trip of dead air per file. With swarm receive, the receiver first grabs the tiny content index, then fans the files out over parallel direct connections — on by default in Extreme (8-wide), LAN Beast (12-wide), and Warp (16-wide), and forceable for every mode in Settings. Every byte stays BLAKE3-verified in the same store, and any failure falls back to the standard path automatically — it is never worse than the default.
Honest scope. The congestion-controller switch is evidence-based (upstream measurements); window/stream/parallelism sizing encodes design intent. On same-machine loopback the modes cluster within ~13% (626 – 710 Mbps median) because loopback is CPU-bound, not congestion-bound. LAN/WAN throughput-delta validation lands in v0.6.
Mode-sweep receipts:AUDIT.md §2.1.1·docs/reports/raw/audit-v0.5.1/mode-sweep/.
The bench tool lives at src-tauri/src/bin/benchmark_local.rs. It generates payloads at runtime (xorshift PRNG), spins up two LightningP2PNode instances in temp dirs, and runs the real sender::create_share + receiver::receive_ticket paths.
Current reference — same-machine loopback, AMD Zen 5 + Windows 11 Build 26200 + NVMe, 5 runs each, schema v2:
| Scenario | Runs | Median total | Export | Effective |
|---|---|---|---|---|
same_machine_10mb |
5/5 | 147 ms | 7 ms | 569.89 Mbps |
same_machine_100mb |
5/5 | 1,356 ms | 7 ms | 618.45 Mbps |
same_machine_1gb |
5/5 | 13,565 ms | 8 ms | 633.21 Mbps |
same_machine_many_small (200 × 100 KB) |
5/5 | 512 ms | 274 ms | 327.05 Mbps |
Caveat: Same-machine loopback only. Not WAN. Not Windows ↔ Android. Not Wi-Fi. Not relay. Don't quote these for "fastest" claims.
◆ Reproduce locally
# Smoke (10 MB only · ~30s)
pnpm bench:local
# Full (10 MB / 100 MB / 1 GB / many-small)
pnpm bench:local:full
# Direct — with explicit mode + hardware notes
.\src-tauri\target\release\benchmark-local.exe `
--profile full --runs 5 --mode standard `
--hardware-notes "AMD Zen 5, Win 11 26200, NVMe" `
--output-dir docs/reports/raw/localRaw JSON + CSV: docs/reports/raw/. Methodology + template: docs/BENCHMARKS.md · docs/benchmark-report-template.md.
Lightning P2P avoids cloud file hosting, but receive tickets are capability tokens. Anyone with a valid ticket can request the content while the sender is online — treat tickets like secrets.
| Property | How |
|---|---|
| Transport | Every byte encrypted by iroh's QUIC stack. TLS 1.3 keys derived per-session. |
| Integrity | BLAKE3 verifies as the receiver streams to disk. Bad bytes surface as structured errors, never silent corruption. |
| Storage | Sender keeps the file on disk until receive completes. There is no upload step to a hosted bucket. |
| Relay | Connectivity help (a hop when NAT blocks the direct path). Not retention. Relay sees encrypted QUIC frames, not plaintext. |
| Diagnostics | Bundles gathered locally, redacted, copied by the user. The frontend never auto-posts transfer secrets. |
| Telemetry | None by default. The native app does not phone home. |
| Sender contract | Keep the sender online until receive finishes. Closing the app cancels in-flight transfers. |
Read SECURITY.md · docs/security-model.md · docs/download-trust.md before using on sensitive machines.
| Capability | Status | |
|---|---|---|
| 🟢 | Windows send + receive (Tauri 2 desktop) | Stable |
| 🟢 | macOS send + receive (universal DMG, Intel + Apple Silicon) | Beta v0.9.9 |
| 🟢 | Linux send + receive (AppImage / deb / rpm) | Beta v0.9.9 |
| 🟢 | Android send + receive (sideload APK) | Stable |
| 🟢 | CLI (lightning-p2p-cli send/receive, pipe-friendly) |
Beta v0.9.9 |
| 🟢 | Lightning Chat Web lounge + encrypted direct messages | Beta v0.9.9 |
| 🟢 | Lightning Chat in Windows and Android native apps | Beta v0.9.9 |
| 🟡 | Encrypted nearby Bluetooth multi-hop chat | Windows + Android beta v0.9.9 |
| 🟢 | Android system share-target + MediaStore routing | Stable v0.4.6 |
| 🟢 | QR + handoff link + raw ticket | Stable |
| 🟢 | Nearby Wi-Fi / LAN discovery (mDNS) | Stable |
| 🟢 | iroh relay fallback when direct path is blocked | Stable |
| 🟢 | Atomic writes + retry/backoff + implicit resume | Stable v0.5.1 |
| 🟡 | Speed modes (6 profiles, BBR on Fast+) | Experimental v0.8.0 |
| 🟡 | Swarm receive (parallel fetches, default-on in Extreme+) | Experimental v0.8.0 |
| 🟡 | Ticket pre-warming (pre-dial on paste) | Experimental v0.8.0 |
| 🟡 | BLE proximity discovery + NFC ticket receive | Experimental since v0.5.0 |
| 🟢 | Receive in any browser — no install, same Rust engine as WASM, BLAKE3-verified | Public beta |
| ⏳ | iOS build, phone-to-phone NFC write, macOS/Linux BLE | Roadmap |
BLE and NFC never carry file bytes — beacons + ticket material only. Bytes always travel through iroh QUIC. Full behavior + hardware test plan: docs/proximity.md.
src/ React + TypeScript marketing + receive shell
src/components/WebLandingPage.tsx cinematic landing (Cabinet Grotesk, motion-led)
src/components/ReceiveHandoffPage.tsx /receive#t=<ticket> handoff
src-tauri/ Rust backend · Tauri 2 IPC · iroh engine
src-tauri/src/node/ endpoint · relay · discovery · nearby ALPN
src-tauri/src/transfer/ send · receive · export · progress · mode profiles
src-tauri/src/storage/ settings · history · peer cache (sled)
src-tauri/src/proximity/ble.rs Windows WinRT BLE (Android peer under gen/)
src-tauri/src/bin/benchmark_local.rs the bench tool
docs/ architecture · trust · release · proximity · audit
scripts/ release verification · benchmark · packaging
AUDIT.md v0.5.1 audit (root level, intentional)
- Networking goes through iroh. No raw sockets, no WebRTC, no HTTP file transfer.
- Blob transfer goes through iroh-blobs. No custom chunking or hashing.
- Frontend ↔ backend communicate through Tauri IPC only. No embedded HTTP server.
- React is presentational. Rust owns transfer logic + persistence.
- Public claims attach to source, release artifacts, or benchmark evidence. No exceptions.
Deeper reading: docs/ARCHITECTURE.md.
Prereqs: Node 22+ · pnpm 10 · Rust 1.81+ · platform Tauri toolchains.
pnpm install
pnpm tauri dev # native desktop app
pnpm dev # web (marketing site)
pnpm android:dev # Android device/emulator (Tauri-Android)PR gate (same matrix CI runs):
pnpm check # release-state + lint + typecheck + test + build + cargoTwo profiles, two windows (test sender ↔ receiver on one machine):
$env:LIGHTNING_P2P_PROFILE = "alice"; pnpm tauri dev
$env:LIGHTNING_P2P_PROFILE = "bob"; pnpm tauri devEnvironment overrides: .env.example.
Bench-time import-parallelism override: $env:LIGHTNING_P2P_IMPORT_PARALLELISM = 16 (positive int).
High-impact areas:
- Device testing on real Windows + Android hardware (LAN, WAN, relay)
- Benchmark reports on different hardware (CPU, NIC, NVMe class) — file a PR with raw JSON
- Accessibility + keyboard nav across the app shell
- Diagnostics + error copy that helps users self-recover
- macOS / Linux packaging spikes (Tauri builders exist; CI is greenfield)
- Proximity validation with physical BLE + NFC hardware
- Docs · screenshots · release verification
Start with CONTRIBUTING.md · docs/README.md · docs/ROADMAP_v0.5_to_v0.7.md.
Apache-2.0 · see also NOTICE.
Citing Lightning P2P in research, posts, or benchmarks? Use CITATION.cff.
◆ ◇ ◆ ◇ ◆ ◇ ◆ ◇ ◆ ◇ ◆ ◇ ◆ ◇ ◆ ◇ ◆ ◇ ◆ ◇ ◆ ◇ ◆ ◇ ◆ ◇ ◆ ◇ ◆ ◇ ◆ ◇ ◆
Built by Horalix · Powered by iroh + iroh-blobs + Tauri · Direct files. Verified bytes. No cloud account.