LocalSend - application open source multiplateforme de partage de fichiers en local qui remplace AirDrop

 (github.com/localsend)
1 points par GN⁺ 1 일 전 | 2 commentaires | Partager sur WhatsApp
  • Application open source gratuite permettant d’échanger en toute sécurité des fichiers et des messages avec des appareils proches sur le réseau local, sans connexion Internet
  • Sans dépendre d’un serveur externe ou tiers, la communication entre appareils s’appuie sur une API REST et le chiffrement HTTPS, pour des échanges locaux rapides et fiables
  • Toutes les données transférées sont protégées par HTTPS, avec génération instantanée de certificats TLS/SSL sur chaque appareil pour renforcer la sécurité
  • Disponible sur Windows, macOS, Linux, Android, iOS et Fire OS, avec recommandation prioritaire d’installation via l’app store ou le gestionnaire de paquets
  • L’application ne dispose pas de fonction de mise à jour automatique ; le README recommande donc d’utiliser les app stores ou les gestionnaires de paquets
  • Les canaux de distribution incluent Winget, Scoop, Chocolatey, EXE et Portable ZIP pour Windows ; l’App Store et Homebrew pour macOS ; Flathub, Nixpkgs, Snap, AUR, DEB, AppImage et TAR pour Linux ; Play Store, F-Droid et APK pour Android ; Amazon pour Fire OS
  • Les versions minimales prises en charge sont Android 5.0, iOS 12.0, macOS 11 Big Sur et Windows 10 ; la dernière version compatible avec Windows 7 est la v1.15.4
  • Sous Linux, des dépendances de la famille xdg-desktop-portal peuvent être requises selon l’environnement de bureau : Gnome nécessite xdg-desktop-portal et xdg-desktop-portal-gtk, KDE nécessite xdg-desktop-portal et xdg-desktop-portal-kde
  • Dans la plupart des cas, aucun réglage supplémentaire n’est nécessaire, mais en cas de problème d’envoi ou de réception, il faut autoriser le trafic entrant TCP/UDP 53317 dans le pare-feu ainsi que le trafic sortant TCP/UDP
  • Si l’AP isolation du routeur est activée, la connexion entre appareils peut être bloquée ; il faut donc la désactiver en cas de problème de détection des appareils
  • Le mode portable s’active en plaçant un fichier settings.json, même vide, dans le même répertoire que l’exécutable ; l’emplacement d’enregistrement des paramètres est alors déplacé vers ce fichier au lieu du chemin par défaut
  • Pour démarrer l’application cachée uniquement dans la zone de notification, on peut utiliser le flag --hidden
  • En cas de lenteur, il est recommandé d’utiliser le 5 Ghz et de désactiver le chiffrement sur les deux appareils ; la baisse de vitesse de réception sur Android reste un problème connu
  • Pour compiler depuis les sources, Flutter et Rust sont nécessaires, et le projet utilise une ancienne version de Flutter spécifiée dans .fvmrc, d’où la recommandation d’utiliser fvm flutter

À lire aussi

2 commentaires

 
xguru 1 일 전

Je l’utilisais souvent pour partager des timelapses pris lors de rencontres de jeux de société.
Récemment, avec le partage de type AirDrop entre Galaxy et Pixel, son utilité est devenue un peu plus floue.
Cela dit, pour envoyer vers un ordinateur de bureau, c’est toujours très bien.
 
GN⁺ 1 일 전
Réactions sur Hacker News

  • Le problème, c’est que toutes ces alternatives exigent d’être sur le même réseau local
    Si j’ai bien compris, le point fort d’AirDrop est justement de créer et gérer ce réseau local automatiquement en arrière-plan
    Du coup, on pouvait envoyer quelque chose immédiatement même en randonnée avec des amis
    Depuis que je suis passé sur Android, je fais un partage de connexion vers l’appareil d’un ami pour créer un LAN, puis j’utilise Localsend, mais l’expérience est nettement moins fluide

    • https://mbarlow.github.io/thinair/
      C’est simplement un outil de transfert d’appareil à appareil qui fonctionne comme une page GitHub statique
      dépôt gh : https://github.com/mbarlow/thinair
      Chaque appareil génère un QR code à scanner, puis établit une connexion WebRTC
      Entre appareils Android, il utilise aussi un chirp audio pour indiquer de passer du mode QR au mode scan avec la caméra
      Je l’ai aussi testé entre Android↔Apple et ça fonctionne, mais Apple ne capte pas ce chirp audio
      Dans ce cas, il suffit d’attendre un peu pour que le QR code disparaisse et passer à l’étape de scan
      C’est un bricolage fait dans l’urgence ; au départ, je voulais expérimenter un handshake audio entre smartphones, avec des chirps façon chant d’oiseau ou à l’ancienne modem
      C’était amusant de coller les téléphones l’un contre l’autre et de faire circuler des trames audio pour confirmer le démarrage du transfert, mais le handshake était lent et peu fiable
      J’aimerais encore peaufiner le flux, et en l’état je l’utilise déjà pour envoyer des fichiers entre iPhone/Android/PC sans app, e-mail ni compte
    • Ce qui se rapprochait le plus d’un vrai P2P cross-platform, c’était FlyingCarpet
      Mais ce n’était ni très stable ni très convivial
      https://github.com/spieglt/FlyingCarpet
    • Ça vaut aussi le coup d’essayer : https://github.com/nuwainfo/ffl
      C’est une app Android, et elle dit ne pas nécessiter de LAN pour le partage
      https://play.google.com/store/apps/details?id=com.fastfilelink.wrapper
    • AirDrop aussi peut se comporter de façon assez bizarre
      Il arrive qu’il ne trouve pas l’autre téléphone, probablement quand un transfert précédent a échoué silencieusement en arrière-plan
      Sans connexion mobile/Wi-Fi, j’ai aussi eu des problèmes pour trouver les contacts, notamment en voulant envoyer des photos à un autre téléphone en montagne
      Parfois ça se fige tout simplement et ça ne marche plus du tout ; cette magie Apple n’aide donc pas beaucoup
    • En réalité, Localsend ne gère que la dernière étape de ce que fait AirDrop
      Pour utiliser Localsend, il faut qu’un appareil crée un Wi‑Fi ad hoc, que les autres appareils s’y connectent, puis seulement lancer Localsend
      Les deux premières étapes sont assez pénibles, et comme AirDrop s’en charge tout seul, l’ensemble paraît bien moins contraignant

  • J’ai commencé à l’utiliser récemment et ça marche vraiment bien, bien plus fiable qu’AirDrop
    Cela dit, l’UX peut encore être améliorée
    J’aimerais quand même qu’Apple corrige un peu AirDrop
    À chaque utilisation, la confiance est trop faible : il ne voit pas les appareils, ou bien s’il y a plusieurs utilisateurs Mac il affiche deux fois le même Mac sans indiquer quel utilisateur correspond à quoi, ce qui est confus

    • Je me demande à quoi les gens s’en servent
      Je ne vois pas vraiment quels gros fichiers ils produisent et déplacent pour avoir autant besoin de ce type d’app
      Dans mon cas, les fichiers qui viennent de mon téléphone sont surtout des photos et vidéos ; je les sauvegarde avec Immich puis je partage un lien
      J’imagine que la plupart des gens font pareil avec iCloud ou Google Photos
      Pour la synchro d’autres fichiers comme des documents, j’utilise ownCloud OCIS, et pour la majorité des gens DropBox, iCloud, voire e-mail ou WhatsApp devraient suffire
      Pour déplacer des ISO ou autre sur un réseau local, on peut simplement copier via SMB, et ça marche pratiquement partout sans app dédiée
      Pour une sauvegarde, on peut aussi simplement brancher un disque dur
      Du coup, je ne vois pas bien pourquoi j’utiliserais ça
    • Je me demande si tu as déjà essayé de dépanner ces problèmes
      J’avais aussi des soucis de visibilité avant, mais dernièrement ça marche toujours plutôt bien chez moi
    • Dans mon cas, les appareils apparaissent, mais quand je lance le transfert, environ une fois sur deux il n’apparaît même pas sur l’appareil cible
      Je n’ai pas encore trouvé de solution fiable ; le mieux reste de couper puis rallumer AirDrop des deux côtés, mais même ça ne marche qu’à environ 70 %

  • Ça vaut le coup de regarder Sendme https://github.com/n0-computer/sendme et AltSendme https://github.com/tonyantony300/alt-sendme
    Les deux utilisent Iroh https://github.com/n0-computer/iroh, un service relay P2P chiffré open source qui permet d’envoyer des données sans serveur central, donc sans vraie limite de taille pour les fichiers envoyés ou reçus
    Je les avais déjà recommandés dans un fil similaire à propos d’apps de partage de fichiers
    https://news.ycombinator.com/item?id=47906587

    • Les services qui demandent de partager un seed/code de cette manière me paraissent toujours un peu maladroits
      Le code n’est ni assez court ni assez simple pour être transmis oralement, et si on peut déjà envoyer ce code, on peut souvent tout aussi bien envoyer directement le fichier lui-même

  • https://github.com/schlagmichdoch/pairdrop
    Projet similaire, mais celui-ci fonctionne entièrement dans le navigateur et peut aussi se connecter à des clients hors du réseau local via une room « public »

    • Il faut vraiment que j’essaie ça
      J’ai installé Localsend pour les transferts entre iPhone et desktop Linux, mais ça ne tourne pas toujours bien
      Même après avoir ouvert les ports Localsend dans Firewalld, il arrive qu’il faille plus de 10 minutes avant que les appareils se voient mutuellement
      Si c’est basé sur le navigateur, au moins la découverte devrait être plus rapide
    • Pairdrop est vraiment bien
      La doc est un peu cachée, mais la FAQ est là : https://github.com/schlagmichdoch/pairdrop/blob/master/docs/faq.md, et
      l’intégration au menu de partage d’Android, iOS et Windows est expliquée ici : https://github.com/schlagmichdoch/PairDrop/blob/master/docs/how-to.md
      C’est un fork de sharedrop et snapdrop, qui ont été cassés après leur rachat par LimeWire
    • Le nom aurait dû être PearDrop

  • Pour tout ce qui se présente comme un remplaçant d’AirDrop, j’ai l’impression qu’il faudrait quelque chose comme spamsolutions.txt
    Celui-ci ne passe pas le critère selon lequel les deux pairs ne doivent pas avoir besoin d’être déjà connectés au réseau Wi‑Fi existant
    https://craphound.com/spamsolutions.txt

  • J’ai déjà sorti quelque chose de semblable avec Tauri
    L’installeur faisait environ 27 Mo sur Mac, 45 Mo en .deb sur Linux et 53 Mo sur Windows ; avec Electron, le plancher tournait plutôt autour de 150 Mo
    La seule exception, c’était le .AppImage à environ 110 Mo, parce qu’il embarque le runtime
    Cette réduction de taille vient du fait qu’on réutilise la webview de l’OS, mais c’est aussi là que se trouve le coût
    WebKitGTK sur Linux se comporte vraiment différemment de WebKit sur Mac ou d’Edge WebView sur Windows, donc on perd tout ce que Chromium gérait à notre place et on passe du temps en debug cross-platform
    Étonnamment, ce qui m’a encore plus surpris que le framework, c’est le packaging Linux
    AppImage tourne partout, mais donne l’impression d’un citoyen de seconde zone pour la plupart des utilisateurs ; le .deb couvre les distributions majeures, mais il faut suivre l’évolution permanente des versions de glibc
    Snap/Flatpak ressemblent à la réponse officielle cross-distro, mais avec les sandbox et la gestion des permissions, un développeur indé peut facilement y perdre des semaines
    Au final, j’ai distribué en .deb et .AppImage, et quelques heures plus tard je recevais déjà des mails du style : « pourquoi ce n’est pas sur l’AUR ? »

  • Ça fonctionne aussi dans le navigateur
    https://web.localsend.org/
    On peut transférer depuis Windows vers Android, iOS, etc.

    • Chez moi, ça n’a pas marché
      J’ai essayé en émission comme en réception avec Firefox, Chrome, téléphone et laptop
      La console affichait WebRTC: ICE failed, add a TURN server and see about:webrtc for more details. et je ne voyais pas du tout comment un utilisateur normal était censé résoudre ça
      En cherchant, je ne trouvais surtout que des conseils destinés aux développeurs
      J’ai fini par comprendre que ça fonctionne si on coupe Tailscale
    • Je me demande comment ils font la découverte LAN dans le navigateur
    • Sympa
      Mais v1.18.0 n’est toujours pas sur F-droid

  • Moi aussi je développais quelque chose dans cet espace l’an dernier
    J’ai essentiellement créé keibidrop, un filesystem peer-to-peer : https://keibidrop.com/
    Je l’ai lancé la semaine dernière, et ça fait ce que fait local send, avec en plus un fonctionnement sur le WAN
    L’app mobile n’est pas encore sortie
    L’étape supplémentaire, c’est qu’il y a aussi un filesystem virtuel synchronisé dans les deux sens
    Le dépôt est ici : https://github.com/KeibiSoft/KeibiDrop
    Le code hors UI est open source, et j’ai aussi fait des benchmarks contre localsend en loopback ; local send était plus rapide
    https://keibisoft.com/blog/keibidrop-benchmarks-vs-competition.html
    Hier, j’ai aussi essayé de lancer un fil de commentaires sur /r/golang
    En interne, j’ai utilisé PQC, gRPC et FUSE

  • C’était l’une des premières apps que j’ai installées après être passé sous Linux
    Ça m’a vraiment fait mesurer à quel point les apps open source peuvent être excellentes

  • Il semble que Localsend ne fonctionne pas encore de manière fiable quand Tailscale est activé
    C’est dommage
    Ce serait vraiment bien qu’il prenne aussi en charge les transferts de fichiers entre clients d’un même tailnet