How LumiHop actually works

Every device sends a small beacon on UDP multicast 239.77.85.77:54545, and on the subnet broadcast address as a fallback. The beacon carries a name, a platform, a port and a public key — never a file, never a filename.

Some networks pass multicast in one direction only, which produces the maddening case where your laptop sees your phone but not the reverse. So a device that hears a beacon also replies directly to the sender, with a flag that stops the two of them bouncing replies at each other forever.

Each device generates an Ed25519 identity key once and keeps it. To connect, the two sides perform an X25519 key exchange, each signing their half so an attacker cannot sit in the middle and substitute their own.

The shared secret is run through HKDF-SHA256 to produce session keys, and — this is the part you see — a six-digit code. Both screens show that code. If they match, nobody is in the middle. If they do not, something is.

After that first pairing the device is remembered, and you are not asked again.

Files are split into 256 KiB chunks, each sealed with ChaCha20-Poly1305. The receiver writes into a .lhpart file and only renames it into place once the whole item’s SHA-256 matches what the sender promised. A file that appears in your downloads folder is a file that arrived intact.

If the connection drops, the partial stays on disk. The sender reconnects on its own, re-offers the same transfer, and continues from the byte it stopped at — you are not asked to approve it again, and nothing already transferred is sent twice.

A web page cannot broadcast on a network — there is no UDP in a browser. So two browsers need something to introduce them, and that introduction is the one piece that cannot happen purely on your Wi-Fi.

LumiHop’s signaling server does that introduction and nothing else. Once the two browsers know about each other they open a WebRTC data channel and the file goes directly between them, over the local network. File contents never reach the signaling server.

Peers are grouped by a salted hash of their public IP address, which is how two phones behind the same router end up in the same room. The raw address is never stored, and the salt rotates daily.

If you want zero contact with the internet, run the desktop app: it can do the introducing itself, on your own network, and the browser app will use it instead.

A security page that only lists strengths is marketing. These are the real edges:

• Anyone on your Wi-Fi can see your device name. Discovery beacons are unencrypted by design — that is how discovery works. They contain no file information, but they do announce that you exist.
• Public-IP grouping can put strangers in your room. Behind carrier-grade NAT — common on mobile networks and in some apartment buildings — people who are not your neighbours can share your public address. Nothing is ever received without you tapping accept, and you can switch to a private room code at any time.
• Some networks stop devices talking to each other at all. Guest Wi-Fi and “client isolation” settings deliberately block devices on the same network from reaching one another, and browsers locate each other using mDNS, which those networks also block. Nothing LumiHop can do fixes that — it is the router doing exactly what it was configured to do.
• The installers are unsigned. Neither Apple nor Microsoft has vouched for these builds, and your operating system will say so. Code signing costs money we have not spent yet. Building from source is the alternative that requires trusting nobody.
• Pairing codes only work if you actually read them. The six digits are the entire defence against a machine-in-the-middle. Tapping Pair without looking defeats it.

The core has no third-party dependencies — no framework, no crypto library beyond what the JDK ships, nothing pulled from a package registry. That is partly a security position and partly a maintenance one: there is no supply chain to compromise because there is no supply chain.

The protocol is documented separately from the implementation, and the two are checked against each other by the test suite, so the spec cannot quietly drift away from the code.