LocalSend – Open-Source-Cross-Platform-App für lokale Dateifreigabe als AirDrop-Alternative

Repository: https://github.com/localsend/localsend

• Eine kostenlose Open-Source-App, mit der sich Dateien und Nachrichten sicher mit nahen Geräten im lokalen Netzwerk austauschen lassen – ganz ohne Internetverbindung
• Sie ist nicht auf externe oder Drittanbieter-Server angewiesen und nutzt für die Kommunikation zwischen Geräten REST API und HTTPS-Verschlüsselung, um schnelle und zuverlässige lokale Kommunikation zu ermöglichen
• Alle Übertragungsdaten werden per HTTPS geschützt, und TLS/SSL-Zertifikate werden auf jedem Gerät sofort erzeugt, um die Sicherheit zu erhöhen
• Verfügbar für Windows, macOS, Linux, Android, iOS und Fire OS; die Installation über App Stores oder Paketmanager wird vorrangig empfohlen
• Die App hat keine automatische Update-Funktion, daher empfiehlt das README die Nutzung von App-Store- oder Paketmanager-Pfaden
• Zu den Distributionskanälen gehören unter Windows Winget, Scoop, Chocolatey, EXE und Portable ZIP, unter macOS App Store und Homebrew, unter Linux Flathub, Nixpkgs, Snap, AUR, DEB, AppImage und TAR, unter Android Play Store, F-Droid und APK sowie unter Fire OS Amazon
• Die mindestens unterstützten Versionen sind Android 5.0, iOS 12.0, macOS 11 Big Sur und Windows 10; die letzte Version mit Unterstützung für Windows 7 ist v1.15.4
• Unter Linux werden je nach Desktop-Umgebung Abhängigkeiten aus der xdg-desktop-portal-Familie benötigt: Gnome erfordert xdg-desktop-portal und xdg-desktop-portal-gtk, KDE erfordert xdg-desktop-portal und xdg-desktop-portal-kde
• In den meisten Fällen funktioniert alles ohne zusätzliche Einrichtung; bei Problemen mit Senden oder Empfangen müssen in der Firewall TCP/UDP 53317 eingehend sowie TCP/UDP ausgehend erlaubt sein
• Ist auf dem Router AP isolation aktiviert, wird die Verbindung zwischen Geräten blockiert; bei Problemen mit der Gerätesuche sollte dies deaktiviert werden
• Der Portable-Modus wird aktiviert, wenn sich im selben Verzeichnis wie die ausführbare Datei eine settings.json-Datei befindet, die auch leer sein darf; dann wird diese Datei statt des Standardpfads zum Speichern der Einstellungen verwendet
• Wenn die App nur minimiert im Tray gestartet werden soll, kann das Flag --hidden verwendet werden
• Bei langsamer Geschwindigkeit wird die Nutzung von 5 Ghz sowie das Deaktivieren der Verschlüsselung auf beiden Geräten empfohlen; eine reduzierte Empfangsgeschwindigkeit unter Android ist weiterhin ein bekanntes Problem
• Für den Build aus dem Quellcode werden Flutter und Rust benötigt; da das Projekt eine in .fvmrc festgelegte ältere Flutter-Version verwendet, wird fvm flutter empfohlen

[xguru]

Ich habe es oft genutzt, um Zeitrafferaufnahmen zu teilen, die ich bei Brettspieltreffen gemacht habe.
In letzter Zeit ist der Einsatzzweck etwas unklar geworden, seit Galaxy und Pixel AirDrop-artiges Teilen unterstützen.
Natürlich ist es immer noch gut, wenn man etwas an den Desktop senden will.

[GN⁺]

Hacker-News-Kommentare

• Das Problem ist, dass all diese Alternativen im Grunde im gleichen lokalen Netzwerk sein müssen.
  So wie ich es verstehe, ist das Gute an Airdrop, dass es dieses lokale Netzwerk im Hintergrund automatisch erstellt und verwaltet.
  Deshalb konnte ich auch beim Wandern mit Freunden sofort etwas verschicken.
  Seit ich auf Android umgestiegen bin, erstelle ich per Tethering ein LAN zum Gerät eines Freundes und nutze dann Localsend, aber das Erlebnis ist insgesamt deutlich weniger nahtlos.

  • https://mbarlow.github.io/thinair/
    Das ist einfach ein Device-to-Device-Transfer-Tool, das als statische GitHub-Seite läuft.
    gh repo: https://github.com/mbarlow/thinair
    Jedes Gerät erzeugt einen QR-Code zum Scannen und baut dann eine WebRTC-Verbindung auf.
    Zwischen Android-Geräten wird auch ein Audio-Chirp verwendet, der ihnen sagt, vom QR-Modus in den Kamerascan-Modus zu wechseln.
    Android↔Apple habe ich ebenfalls getestet, und es funktioniert zwar, aber Apple erkennt diesen Audio-Chirp nicht.
    In dem Fall wartet man einfach kurz, bis der QR-Code verschwindet und man zum Scan-Schritt übergehen kann.
    Das Ganze ist schnell zusammengehackt; ursprünglich habe ich mit vogelähnlichen Chirps oder alten Modem-Methoden experimentiert, um einen Audio-Handshake zwischen Smartphones hinzubekommen.
    Es war unterhaltsam, die Telefone aneinanderzuhalten und Audio-Frames hin- und herzuschicken, um den Start der Übertragung zu bestätigen, aber der Handshake war langsam und unzuverlässig.
    Ich möchte den Ablauf noch weiter verfeinern und nutze es schon jetzt, um Dateien zwischen iPhone/Android/PC ohne App, E-Mail oder Account zu verschicken.
  • Am nächsten an echtem Cross-Platform-P2P war FlyingCarpet.
    Allerdings war es weder besonders stabil noch besonders benutzerfreundlich.
    https://github.com/spieglt/FlyingCarpet
  • Das hier könnte ebenfalls einen Versuch wert sein: https://github.com/nuwainfo/ffl
    Eine Android-App, die laut Beschreibung beim Teilen kein LAN benötigt.
    https://play.google.com/store/apps/details?id=com.fastfilelink.wrapper
  • Airdrop verhält sich manchmal auch ziemlich seltsam.
    Manchmal findet es das andere Telefon nicht, vermutlich wenn ein vorheriger Transfer im Hintergrund stillschweigend fehlgeschlagen ist.
    Ohne Mobilfunk-/Wi‑Fi-Verbindung gab es auch Probleme bei der Kontaktsuche; das hatte ich mal, als ich in den Bergen Fotos an ein anderes Telefon senden wollte.
    Manchmal hängt es sich einfach auf und funktioniert dann gar nicht mehr, daher hilft diese Apple-Magie nicht besonders.
  • Localsend übernimmt in Wirklichkeit nur den letzten Schritt von dem, was Airdrop macht.
    Um Localsend zu nutzen, muss man auf einem Gerät ein Ad-hoc-Wi‑Fi erstellen, die anderen Geräte damit verbinden und erst dann Localsend starten.
    Die ersten beiden Schritte sind ziemlich umständlich, und Airdrop erledigt das automatisch, weshalb es sich viel reibungsloser anfühlt.

• Ich habe es erst vor Kurzem benutzt, und es funktioniert wirklich gut und war deutlich zuverlässiger als Airdrop.
  Beim UX gibt es aber noch Luft nach oben.
  Trotzdem wünschte ich, Apple würde Airdrop etwas reparieren.
  Ich habe jedes Mal nur sehr wenig Vertrauen hinein; manchmal sieht es Geräte nicht, und wenn mehrere Mac-Nutzer da sind, zeigt es denselben Mac zweimal an, ohne zu sagen, welcher Nutzer welcher ist, was verwirrend ist.

  • Ich frage mich, wofür alle das eigentlich nutzen.
    Ich verstehe nicht ganz, welche großen Dateien Leute überhaupt erzeugen und verschieben, sodass man so eine App braucht.
    Bei mir entstehen auf dem Handy nur Fotos und Videos; die sichere ich mit Immich und teile dann einfach den Link.
    Ich nehme an, normale Leute machen Ähnliches mit iCloud oder Google Photos.
    Für die Synchronisation anderer Dateien wie Dokumente nutze ich ownCloud OCIS, und für die meisten dürfte DropBox oder iCloud oder auch E-Mail oder WhatsApp reichen.
    Wenn ich im lokalen Netzwerk Dinge wie ISOs verschieben will, kopiere ich sie einfach per SMB; das geht praktisch überall und braucht keine extra App.
    Für Backups kann man auch einfach eine Festplatte anschließen.
    Deshalb leuchtet mir nicht wirklich ein, warum ich das benutzen sollte.
  • Mich würde interessieren, ob du diese Probleme schon getroubleshootet hast.
    Früher hatte ich auch Sichtbarkeitsprobleme, aber inzwischen funktioniert es bei mir eigentlich immer.
  • Bei mir werden die Geräte zwar angezeigt, aber wenn ich die Übertragung starte, erscheint sie in etwa der Hälfte der Fälle auf dem Zielgerät überhaupt nicht.
    Einen sicheren Fix habe ich noch nicht gefunden; am besten hilft es, Airdrop auf beiden Seiten aus- und wieder einzuschalten, aber selbst das funktioniert nur zu etwa 70 %.

• Sendme https://github.com/n0-computer/sendme und AltSendme https://github.com/tonyantony300/alt-sendme sind einen Blick wert.
  Beide verwenden Iroh https://github.com/n0-computer/iroh, einen Open-Source-verschlüsselten P2P-Relay-Dienst, der Daten ohne zentralen Server versendet, sodass es praktisch keine Größenbeschränkung für gesendete oder empfangene Dateien gibt.
  Ich habe das auch schon in ähnlichen Threads empfohlen, wenn es um File-Sharing-Apps ging.
  https://news.ycombinator.com/item?id=47906587

  • Solche Dienste, bei denen man auf diese Weise einen Seed/Code teilen muss, wirken immer etwas unbeholfen.
    Der Code ist weder kurz noch einfach genug, um ihn mündlich zu übermitteln, und wenn man den Code verschicken kann, kann man meistens auch einfach direkt die Datei verschicken.

• https://github.com/schlagmichdoch/pairdrop
  Ein ähnliches Projekt, aber dieses läuft komplett im Browser und kann über einen "public" room auch Clients außerhalb des lokalen Netzwerks verbinden.

  • Das muss ich unbedingt ausprobieren.
    Ich habe Localsend für Transfers zwischen iPhone und Linux-Desktop installiert, aber es läuft nicht immer zuverlässig.
    Selbst wenn ich den Localsend-Port in Firewalld freigebe, dauert es manchmal mehr als 10 Minuten, bis sich die Geräte überhaupt sehen.
    Browserbasiert sollte zumindest die Discovery schneller sein.
  • Pairdrop ist wirklich gut.
    Die Dokumentation ist etwas versteckt, aber die FAQ ist hier: https://github.com/schlagmichdoch/pairdrop/blob/master/docs/faq.md,
    und die Integration in die Teilen-Menüs von Android, iOS und Windows steht hier: https://github.com/schlagmichdoch/PairDrop/blob/master/docs/how-to.md
    Es ist ein Fork von sharedrop und snapdrop, nachdem diese von LimeWire übernommen und ruiniert wurden.
  • Der Name hätte PearDrop sein sollen.

• Bei Dingen, die sich als Airdrop-Ersatz bezeichnen, hat man das Gefühl, man bräuchte so etwas wie spamsolutions.txt.
  Dieses hier erfüllt das Kriterium nicht, dass beide Peers nicht bereits in einem bestehenden Wi‑Fi-Netzwerk hängen dürfen.
  https://craphound.com/spamsolutions.txt

• Ich habe auch einmal etwas Ähnliches mit Tauri herausgebracht.
  Die Installationsgröße lag bei etwa 27 MB auf dem Mac, 45 MB als Linux-.deb und 53 MB unter Windows; bei Electron lag das Minimum eher bei 150 MB.
  Nur die .AppImage war mit etwa 110 MB eine Ausnahme, weil dort die Runtime mitgebündelt wird.
  Diese Größenersparnis kommt daher, dass das OS-Webview wiederverwendet wird, aber genau das ist gleichzeitig der Preis dafür.
  WebKitGTK auf Linux verhält sich wirklich anders als WebKit auf dem Mac oder Edge WebView unter Windows, sodass man viel Zeit in Cross-Platform-Debugging steckt statt das von Chromium abfangen zu lassen.
  Überraschenderweise war noch frustrierender als das Framework selbst das Linux-Packaging.
  AppImage läuft zwar überall, fühlt sich für die meisten Nutzer aber wie ein Bürger zweiter Klasse an; .deb deckt die Mainstream-Distributionen ab, aber man muss ständig bewegliche glibc-Versionen im Blick behalten.
  Snap/Flatpak wirken wie die offizielle Cross-Distro-Antwort, aber wegen Sandbox und Rechteverwaltung kann ein Indie-Entwickler damit leicht Wochen verlieren.
  Am Ende habe ich .deb und .AppImage ausgeliefert, und innerhalb weniger Stunden kamen die ersten E-Mails mit der Frage, warum es nicht im AUR sei.

• Funktioniert auch im Browser.
  https://web.localsend.org/
  Transfers von Windows zu Android und iOS sind möglich.

  • Bei mir hat das nicht funktioniert.
    Ich habe Sender und Empfänger mit Firefox, Chrome, Handy und Laptop ausprobiert.
    In der Konsole stand WebRTC: ICE failed, add a TURN server and see about:webrtc for more details., und ich hatte keine Ahnung, wie ein Nutzer das lösen soll.
    Wenn man danach sucht, findet man meist nur Ratschläge für Entwickler.
    Am Ende habe ich herausgefunden, dass es funktioniert, wenn man Tailscale deaktiviert.
  • Ich frage mich, wie LAN-Discovery im Browser umgesetzt wird.
  • Schön.
    Allerdings ist v1.18.0 bei F-droid noch nicht angekommen.

• Ich habe letztes Jahr auch in diesem Bereich an etwas gearbeitet.
  Im Grunde habe ich keibidrop gebaut, ein Peer-to-Peer-Filesystem: https://keibidrop.com/
  Ich habe es letzte Woche veröffentlicht; zusätzlich zu dem, was local send macht, funktioniert es auch über WAN.
  Eine Mobile-App gibt es noch nicht.
  Der nächste Schritt darüber hinaus ist, dass es sogar ein in beide Richtungen synchronisiertes virtuelles Filesystem gibt.
  Das Repository ist hier: https://github.com/KeibiSoft/KeibiDrop
  Abgesehen vom UI ist der Code Open Source, und ich habe es auch gegen localsend auf Loopback-Basis benchmarked, wobei local send schneller war.
  https://keibisoft.com/blog/keibidrop-benchmarks-vs-competition.html
  Gestern habe ich auch versucht, einen Kommentar-Thread dazu auf /r/golang zu starten.
  Intern habe ich PQC, gRPC und FUSE verwendet.

• Nachdem ich zu Linux gewechselt war, war das eine der ersten Apps, die ich installiert habe.
  Daran habe ich wirklich gemerkt, wie gut Open-Source-Apps sein können.

• Es sieht so aus, als würde Localsend derzeit nicht zuverlässig funktionieren, wenn Tailscale aktiviert ist.
  Das ist schade.
  Es wäre wirklich großartig, wenn auch Dateiübertragungen zwischen Clients im selben tailnet unterstützt würden.