Skip to content

About

Send files between devices without a cloud upload or account. Open-source P2P transfer and chat, built with Rust, Tauri, QUIC & BLAKE3. Desktop, Android, browser receiver & CLI; availability varies by release.

Topics

Resources

Code of conduct

Contributing

Security policy

Stars

41 stars

Watchers

2 watching

Forks

Latest commit

 

History

368 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Lightning P2P

Lightning P2P

Private chat. Direct files. One account-free app.

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 ◆

Stars License: Apache-2.0 Platforms Experimental Rust Tauri 2 iroh QUIC BLAKE3

Download · Website · Lightning Chat · AUDIT.md · Roadmap · Changelog · Security


Animated flow: the sender app streams BLAKE3-verified chunks over iroh QUIC — direct first, relay fallback — to any receiver, including a browser tab running the same Rust engine as WebAssembly

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.

Lightning P2P demo: drop a file, share the ticket, receiver streams verified bytes

◆ Why people use it

🚀 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.
📊 Progress stays visible Track phase, progress, speed, and paused transfers while moving between app views.
💬 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

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.


◆ Receive in any browser · public beta

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-blobs core, compiled to WebAssembly (web-receiver/).
  • No cloud file hosting — the ticket stays in the URL fragment and is not included in the page request. Browser peers use an encrypted iroh relay because browsers cannot hole-punch; the relay forwards traffic but does not host files.
  • Honest limits — browser sending is memory-backed, warns past 500 MiB, and refuses past 2 GiB. Browser receiving streams verified chunks to a chosen file in browsers with the File System Access API; other browsers use a 128 MiB aggregate memory limit. Browser peers use encrypted relay transport, and the tab must stay open while sharing or receiving.

◆ What it is, what it isn't

✓ Best fit ✗ Not for
Moving large builds, databases, media between desktops Browser send shares beyond 2 GiB or memory-backed browser receives beyond 128 MiB (use a supported browser sink or the native app for larger receives)
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

◆ Install

Stable channel: v0.4.6. Latest beta release: v0.9.31 (community desktop builds and CLI; receive links open at app launch and route to the running desktop window; retry-safe verified-save confirmations; responsive nearby discovery; consent per recipient; actionable startup recovery; and size-bounded startup state). Flick & Catch shows the file arriving from the approximate side you flick toward; no location data is shared. Tapping Send remains a normal directionless send.

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.31 10.15+ · Intel + Apple Silicon · unsigned: right-click → Open
Linux LightningP2P-linux-x86_64.AppImage Beta v0.9.31 Portable AppImage · .deb / .rpm also published
Android LightningP2P-android-latest.apk Beta v0.9.26 Android 10+ sideload · signed APK/AAB · Lightning Chat + Bluetooth mesh included
CLI lightning-p2p-cli Beta v0.9.31 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.31 Signed web rooms · encrypted DMs · native nearby chat
Latest release Release v0.9.31 Community builds Receive links open on cold start and running desktop · retry-safe save receipts · bounded startup state · same-side Flick arrival
# 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.apk

The 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.


◆ Screenshots & product tour

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.

Lightning P2P transfer overview showing direct-path QUIC, BLAKE3 verification, relay fallback, and signed releases
Direct first, verified end to end. Relay is the encrypted fallback, not a cloud upload.

◆ How it works

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
Loading
  1. Sender picks files / folders / an Android share-sheet item.
  2. Rust engine imports content into the local iroh-blobs store.
  3. A receive ticket is generated (NodeId + content hash + format).
  4. Receiver opens a QR, HTTPS handoff link, deep link, or pastes the raw ticket.
  5. iroh dials direct QUIC; falls back to an encrypted relay-assisted route when NAT blocks the path. The relay carries traffic and is not cloud file storage.
  6. iroh-blobs streams BLAKE3-verified bytes to the destination.

Handoff URLs use /receive#t=<ticket> — browsers omit URL fragments from HTTP requests, so the ticket is not included in the page request. Scripts running on the page can still read it.


◆ Speed modes v0.8.0

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/.


◆ Benchmarks

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/local

Raw JSON + CSV: docs/reports/raw/. Methodology + template: docs/BENCHMARKS.md · docs/benchmark-report-template.md.


◆ Security model

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.


◆ What works today

Capability Status
🟢 Windows send + receive (Tauri 2 desktop) Stable
🟢 macOS send + receive (universal DMG, Intel + Apple Silicon) Beta v0.9.31
🟢 Linux send + receive (AppImage / deb / rpm) Beta v0.9.31
🟢 Android send + receive (sideload APK) Stable
🟢 CLI (lightning-p2p-cli send/receive, pipe-friendly) Beta v0.9.31
🟢 Lightning Chat Web lounge + encrypted direct messages Beta v0.9.31
🟢 Lightning Chat in Windows and Android native apps Windows beta v0.9.31; Android v0.9.26
🟡 Encrypted nearby Bluetooth multi-hop chat Windows beta v0.9.31; Android v0.9.26
🟢 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.


◆ Architecture

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)

Architecture rules — enforced by code review

  1. Networking goes through iroh. No raw sockets, no WebRTC, no HTTP file transfer.
  2. Blob transfer goes through iroh-blobs. No custom chunking or hashing.
  3. Frontend ↔ backend communicate through Tauri IPC only. No embedded HTTP server.
  4. React is presentational. Rust owns transfer logic + persistence.
  5. Public claims attach to source, release artifacts, or benchmark evidence. No exceptions.

Deeper reading: docs/ARCHITECTURE.md.


◆ Develop

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 + cargo

Two profiles, two windows (test sender ↔ receiver on one machine):

$env:LIGHTNING_P2P_PROFILE = "alice"; pnpm tauri dev
$env:LIGHTNING_P2P_PROFILE = "bob";   pnpm tauri dev

Environment overrides: .env.example. Bench-time import-parallelism override: $env:LIGHTNING_P2P_IMPORT_PARALLELISM = 16 (positive int).


◆ Contributing

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.


◆ License + citation

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.

About

Send files between devices without a cloud upload or account. Open-source P2P transfer and chat, built with Rust, Tauri, QUIC & BLAKE3. Desktop, Android, browser receiver & CLI; availability varies by release.

Topics

Resources

Code of conduct

Contributing

Security policy

Stars

41 stars

Watchers

2 watching

Forks

Releases

Sponsor this project

Packages

Contributors

Languages