The Problem

Moving files between devices without shared infrastructure is still painful. USB drives fail across filesystems, cloud services need accounts and bandwidth, and AirDrop is Apple-only. FlyingCarpet solves this by creating an ad hoc WiFi link between any two devices with wireless chips—no router, no internet, no account.

What This Does

FlyingCarpet is a cross-platform file transfer tool covering Android, iOS, Linux, macOS, and Windows. The repository contains a Rust core library (core/) that handles the transfer logic, a Tauri-based desktop app (Flying Carpet/src-tauri/) with a web frontend (Flying Carpet/src/index.html, main.js), and a Kotlin Android app (Android/). The core is split per-OS: core/src/linux/ and core/src/windows/ each have network.rs, bluetooth.rs, central.rs, and peripheral.rs modules.

Version 9 added Bluetooth for transfer negotiation—the WiFi hotspot handles bulk data, while Bluetooth exchanges keys and device info first. The core/src/sending.rs and core/src/receiving.rs modules handle chunked, encrypted file transfer.

How It Is Wired

Execution starts at start_async in Flying Carpet/src-tauri/src/main.rs:118, which reaches 55 functions—the widest blast radius in the repo. The path to real work is short: start_async -> start_transfer -> send_file, where send_file in core/src/sending.rs leaves the process via File::open to read the file off disk. No database, no network service—the filesystem is the only external effect.

The call graph resolves 113 internal edges. fc_error is called from 19 places and output from 12, making both load-bearing: change their signatures and the most code breaks. negotiate_bluetooth is the busiest hub, calling process_bluetooth_message 13 times, unpair 7 times, and generate_password 3 times—it orchestrates the Bluetooth handshake before WiFi transfer begins.

File-by-file map:

  • Flying Carpet/src-tauri/src/main.rs — Tauri commands: output, show_progress_bar, show_pin, cancel_transfer. Called from 8 files.
  • core/src/utils.rs — run_command, get_key_and_ssid, hash_file. Called from 6 files.
  • core/src/linux/network.rs — start_hotspot, stop_hotspot, join_hotspot, connect_to_peer. Called from 4 files.
  • core/src/error.rs — error types. Called from 7 files.
  • core/src/windows/network.rs — the only module running external commands (run_shell_execute), via stop_hotspot and connect_to_peer.

The module graph is clean: 2 internal modules, 1 import edge, no circular dependencies.

How To Use It

git clone https://github.com/moses-y/FlyingCarpet
cd FlyingCarpet
cargo install tauri-cli
cargo tauri dev        # development
cargo tauri build      # release artifacts

Linux requires system dependencies listed in the README (libsoup2.4*, libwebkit2gtk*, etc.). The Android app builds via Gradle in Android/FlyingCarpet/. No environment variables or config files are required—the app handles everything at runtime.

Real-World Use

A consultant needs to move a 4GB database dump from a client's Windows laptop to a Linux server in a room with no network. Both machines run FlyingCarpet, one hosts a hotspot, the other joins it, and the transfer completes over direct WiFi. No flash drive, no cloud, no filesystem format issues.

Code Health & Issues

Measured findings from static analysis (19 total: 2 high, 15 medium, 2 low):

  • High — Deep nesting — max indentation depth of 9 in core/src/windows/central.rs, Android/.../Bluetooth.kt, and Android/.../MainActivity.kt. Flatten with early returns and guard clauses.
  • High — Duplicated code — 19 repeated 6-line blocks across core/src/linux/bluetooth.rs, core/src/windows/bluetooth.rs, core/src/linux/network.rs, and core/src/windows/network.rs. Extract shared helpers.
  • Medium — High branching density — 56 branch points over 181 lines in core/src/linux/central.rs and the Windows modules.
  • Low — TODO/FIXME markers — 8 unresolved markers in core/src/windows/network.rs and core/src/windows/peripheral.rs.

SDLC observations: no CI/CD pipeline exists—26 source files merge without an automated build gate. No Dependabot or Renovate is configured despite 3 manifest files. Tests exist (2 test files) but are minimal.

The Bottom Line

Solid, practical codebase for a genuinely useful tool. The core logic is well-factored per-OS, but the Windows and Linux modules carry duplicated logic and deep nesting that will slow future changes. The lack of CI is the biggest risk—any change can break the build silently. Worth using for the transfer capability; worth adding CI before contributing.