Flying Carpet: Dateiübertragung über Ad-hoc-WLAN oder gemeinsame Netzwerke

Was dieses Repository beschreibt

Flying Carpet ist ein in Rust geschriebenes Dateiübertragungswerkzeug, das Dateien zwischen Android, iOS, Linux, macOS und Windows senden und empfangen kann. Die README stellt zwei Modi vor. Im Hotspot-Modus erstellt ein Gerät einen Ad-hoc-WLAN-Hotspot, dem das andere beitritt. Im Shared-Network-Modus treten beide Geräte demselben bestehenden WLAN- oder kabelgebundenen Netzwerk bei. Keiner der Modi benötigt eine Internet- oder Mobilfunkverbindung; erforderlich sind zwei Geräte mit WLAN- oder Ethernet-Chips (Bluetooth ist optional) und, im Hotspot-Modus, eine geringe Entfernung. Die Repository-Metadaten nennen es "Cross-platform AirDrop", aber die README selbst verwendet diesen Ausdruck nicht. Sie betont stattdessen, dass keine Netzwerkinfrastruktur über die beiden Geräte hinaus erforderlich ist.

Version 10 und der Shared-Network-Modus

Die README beginnt mit einer Warnung: Version 10 ist eine bahnbrechende Änderung. Geräte mit Version 10 können nicht mit Version 9 oder älter übertragen; der Benutzer erhält eine Versionskonfliktmeldung. Alle an einer Übertragung beteiligten Geräte müssen daher Version 10 verwenden. Version 10 fügt den Shared-Network-Modus für Fälle hinzu, in denen der Benutzer ein bestehendes WLAN- oder kabelgebundenes Netzwerk nutzen möchte, anstatt einen Hotspot zu erstellen. In diesem Modus generiert das empfangende Gerät ein Einmalpasswort und zeigt es mit einem QR-Code an. Das sendende Gerät gibt das Passwort ein oder scannt den Code mit einem Telefon, dann finden sich die Geräte im Netzwerk und starten die Übertragung. Bluetooth ist nicht beteiligt, und keines der Geräte muss das Betriebssystem des anderen kennen.

Hotspot-Modus und die Apple-Einschränkung

Im Hotspot-Modus hostet ein Gerät einen Ad-hoc-WLAN-Hotspot, dem das andere beitritt. Wenn beide Geräte Bluetooth unterstützen, tauschen sie die Hotspot-Zugangsdaten automatisch aus, nachdem der Benutzer einen Pairing-Code bestätigt hat. Andernfalls zeigt der Host das Passwort und einen QR-Code zur Eingabe auf dem beitretenden Gerät an. Eine bemerkenswerte Einschränkung: Apple-Geräte können Hotspots nicht programmgesteuert starten, daher müssen Apple-zu-Apple-Übertragungen den Shared-Network-Modus verwenden. Die README schlägt vor, beide Geräte in dasselbe WLAN-Netzwerk zu bringen, das selbst ein manuell auf einem iPhone oder MacBook aktivierter persönlicher Hotspot sein kann, und dann eine Shared-Network-Übertragung durchzuführen. Sie warnt auch, dass der Hotspot-Modus die drahtlose Internetverbindung deaktiviert, außer im Shared-Network-Modus und wenn Windows oder Android den Hotspot hostet. macOS wechselt bei besonders langen Übertragungen möglicherweise zurück zu einem internetverbundenen WLAN.

Verschlüsselungsdetails aus der README

Die README beschreibt die Übertragungsverschlüsselung konkret. Jede Übertragung wird in einen Noise-Protokoll-Handshake NNpsk0 mit X25519, ChaCha20-Poly1305 und SHA-256 eingebettet. Beide Geräte leiten einen vorab geteilten Schlüssel aus dem Übertragungspasswort mit PBKDF2-HMAC-SHA256 bei 600.000 Iterationen ab und führen dann einen ephemeren Diffie-Hellman-Handshake gemischt mit diesem Schlüssel durch. Dateinamen, Größen, Hashes und Inhalte werden nach einer kurzen Klartext-Präambel verschlüsselt; die Präambel selbst ist als Noise-Prolog an den Handshake gebunden, sodass Manipulation die Übertragung abbricht. Jede Übertragung erhält frische Schlüssel, was Vorwärtsgeheimnis bietet. Die README erklärt, dass PBKDF2 anstelle eines speicherharten KDF gewählt wurde, weil iOS und macOS nur Apples CryptoKit verwenden, das weder Scrypt noch Argon2 anbietet. Ein separates Designdokument, docs/shared-network-crypto.md, wird für das vollständige Schema angeführt.

Plattformanforderungen und bekannte Grenzen

Die Android-Version benötigt mindestens Android 10/API-Level 29. Die README berichtet, dass sie auf einigen Xiaomi-, MIUI- oder HarmonyOS-Geräten nicht funktioniert, wahrscheinlich wegen fehlender Unterstützung der LocalOnlyHotspot-API, obwohl sie auf mindestens einem Xiaomi-Telefon bestätigt wurde. Windows erfordert Windows 10 oder höher. Die Linux-Version wurde auf Linux Mint entwickelt und getestet; der Autor sagt, sie sei hauptsächlich für Debian-basierte Distributionen gedacht. Es gibt mindestens ein Problem bei der Ausführung auf Fedora, möglicherweise im Zusammenhang mit SELinux, aber der Autor weiß es nicht sicher. Auf Desktop-Plattformen kann das Klicken auf Abbrechen Zeit in Anspruch nehmen, weil das Betriebssystem möglicherweise noch einen Hotspot beitritt oder erstellt; die README bittet darum, Abbrechen nur einmal zu klicken und ein paar Sekunden zu warten.

Downloads und Build-Pfade

Android-Builds werden über Google Play, F-Droid und als APK auf der GitHub-Releases-Seite verteilt. iOS ist im App Store unter "Flying Carpet File Transfer" erhältlich. Linux-, macOS- und Windows-Binärdateien befinden sich alle auf der Releases-Seite: Linux hat eine .AppImage für den eigenständigen Gebrauch und ein .deb für Debian-basierte Distributionen, macOS hat eine .zip, die in Applications gezogen oder mit brew install flying-carpet installiert werden kann, und Windows hat einen .msi-Installer sowie eine eigenständige FlyingCarpet.exe. Zum Kompilieren aus dem Quellcode sagt die README, man solle Rust installieren, Tauri CLI mit cargo install tauri-cli installieren, Linux-Abhängigkeiten installieren (ein Ubuntu-20-Beispiel wird gegeben) und dann cargo tauri dev oder cargo tauri build ausführen. Der Android-Build läuft von Android/FlyingCarpet/ mit ./gradlew assembleDebug. Die iOS- und macOS-Builds erfordern Xcode; DEVELOPMENT_TEAM ist absichtlich leer, sodass der erste Build fehlschlägt, bis der Benutzer ein Team in Signing & Capabilities auswählt oder DEVELOPMENT_TEAM=YOURTEAMID an xcodebuild übergibt.

Herkunft und Projektzustand

Ein Q&A in der README erklärt, dass das Repository ursprünglich Go war. Der Autor wechselte zu Rust wegen mehrerer Probleme im Go/Qt-Paradigma, insbesondere unter Windows: kein einzelnes ausführbares File, die Notwendigkeit, als Administrator auszuführen, und die Notwendigkeit, eine WiFi-Direct-DLL in einen temporären Ordner zu schreiben und zur Laufzeit zu verlinken. Das GUI-Framework ist jetzt Tauri. Die Android-Version ist in Kotlin geschrieben, die iOS- und macOS-Versionen in Swift; der Swift-Code ist eine unabhängige Portierung des Protokolls und teilt keinen Code mit dem Rust-Kern. Seit v10 liegt der Apple-Code in diesem Repository unter Apple/. Das einzige geplante Feature ist das Hinzufügen einer Flying-Carpet-Verknüpfung zum iOS-Share-Menü. Die Repository-Metadaten zeigen 5.259 Sterne, 256 Forks, 16 offene Issues und kein Archiv-Flag. Die Lizenz ist laut Metadaten GPL-3.0, aber die bereitgestellten Materialien enthalten keinen Lizenztext, daher können hier keine spezifischen Lizenzbedingungen zitiert werden.

Redaktionelles Fazit

Flying Carpet zielt auf das konkrete Problem, Dateien zwischen Geräten zu verschieben, die sich nicht in einem gemeinsamen Netzwerk befinden und keinen Internetzugang haben. Der Shared-Network-Modus von Version 10 erweitert diese Reichweite, aber die Versionsgrenze und plattformspezifische Einschränkungen sind die Fakten, die ein Nutzer vor der Verwendung prüfen sollte.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes