Overview
This series explains how LocalSend turns nearby devices into direct transfer peers without relying on a transport service in the ordinary v2 LAN path. It separates reachability, discovery, certificate-backed identity, receiver consent, session and file authorization, byte integrity, and recovery, then connects those mechanisms to Flutter, Rust, the CLI, browser links, and optional WebRTC signaling. The result is a conditional decision model: direct local control is useful when the network and trust assumptions hold, but the retained source does not prove universal security, speed, or availability.
Learning outcomes
- LocalSend separates reachability, discovery, identity, consent, integrity, and recovery; success in one layer does not prove the others.
- In native HTTPS mode, discovery supplies a fingerprint for handshake-time pinning, but first contact remains trust on first use.
- Preparation authorizes accepted files through a session and per-file tokens; parallel uploads stay within one controlled session.
- The Flutter app currently disables WebRTC; its signaling design would add an external control-plane dependency.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
How does LocalSend find and confirm nearby devices?
LocalSend announces devices over UDP multicast and confirms them with HTTP registration. If multicast fails, it probes known channels, scans likely IPv4 /24 subnets, or accepts a manual address; confirmation still depends on a reachable server.
How does LocalSend authorize a file transfer?
LocalSend lets the receiver review offered metadata and reject all files, accept a subset, or accept the whole request before upload begins. The server then issues a session ID and per-file tokens that it validates during upload.
What does LocalSend HTTPS protect against?
LocalSend's native HTTPS mode encrypts peer traffic and pins certificate fingerprints after discovery, but first contact remains trust on first use. Browser links may use HTTP, and the source does not establish universal protection against every hostile-LAN scenario.
Why does LocalSend use both Flutter and Rust?
Flutter owns user policy and platform destinations, while Rust owns networking, cryptography, sessions, and cleanup; an isolate keeps long-lived work away from the main UI. The CLI reuses the same core with a different interface.
When is LocalSend a good fit?
LocalSend is a good fit when nearby devices can reach each other, both parties accept the local trust model, and keeping the ordinary v2 path on the LAN matters. It is a poor fit when network isolation or blocked servers dominate, and the source does not prove universal reliability or speed.