LocalSend：近距離デバイス間のファイル共有のためのオープンソース・クロスプラットフォーム

 (localsend.org)
4 ポイント 投稿者 GN⁺ 2024-03-11 | 1件のコメント | WhatsAppで共有
  • LocalSendは、クラウドや中継サーバーなしで同じローカルネットワーク上のデバイス同士でファイルを送受信できるため、AirDropのような機能を複数のプラットフォームで使いたいユーザーに有用
  • Windows、macOS、Linux、Android、iOSに対応し、アカウントやログインなしでインストール後すぐに近距離ファイル転送を始められる
  • 転送データはローカルWiFiネットワークの外に出ず、すべての転送でHTTPS暗号化を使用
  • 写真、動画、文書、テキストなどファイル形式の制約はなく、デフォルトの保存先はデバイスのDownloadsフォルダーだが、設定で変更できる
  • 70k+ GitHub Stars、5M+ ダウンロード、100+ コントリビューターを擁する無料のオープンソースプロジェクトで、広告・トラッカー・隠れた費用はない

ローカルネットワークベースのファイル共有

  • LocalSendは、クラウドなしでファイルを共有するオープンソースのクロスプラットフォームツール
  • 対応プラットフォームはWindows、macOS、Linux、Android、iOS
  • 利用の流れはシンプル
    • 各デバイスにLocalSendをインストールして起動する
    • 写真、動画、文書、テキスト、またはその他のファイル形式を選択する
    • 近くのデバイスをタップすると、ローカルネットワーク経由で転送される
  • アカウント、ログイン、サーバーは不要
  • インターネット接続なしで動作し、データはローカルWiFiネットワークの外に出ない
  • WiFiネットワークの最大速度で転送し、帯域幅制限はない
  • すべての転送はHTTPSで暗号化される
  • 追加のセキュリティが必要な場合は、PIN確認を有効にできる
  • ファイルはデフォルトでデバイスのDownloadsフォルダーに保存され、設定で保存先を変更できる

プロジェクトの状況とサポートチャネル

  • LocalSendは100%無料のオープンソースで、広告、追跡、隠れた費用はない
  • 公開指標は70k+ GitHub Stars、5M+ ダウンロード、100+ コントリビューター規模
  • Web版はweb.localsend.orgで提供されている
  • コミュニティとサポートチャネル
    • Discord
    • Reddit
    • Mastodon
    • GitHub Discussionsの言語別ディスカッション：English, Deutsch, Español, Français, Italiano, 简体中文
  • バグはGitHub Issuesで報告できる

関連記事

1件のコメント

 
GN⁺ 2024-03-11
Hacker Newsのコメント

  • 一番良い点は、主要なプラットフォームのほとんどで使えて、GUIが使いやすいこと
    iOSアプリも素晴らしい
    ただし注意すべきバグがいくつかある: WindowsではLocalSendのウィンドウを開いた状態で実行中だと（受信後？）システムのスリープが妨げられ、Linuxではウィンドウが見えていなくても同じことが起きる
    LinuxでLocalSendのウィンドウを表示したままアイドル状態にすると、デスクトップのウィンドウマネージャーが損傷領域を更新し続けてCPUを異常に多く消費する
    Windowsでは「startup minimized」オプションを有効にして起動時に実行するようにしても、ウィンドウがそのまま表示されることが多く、スリープの問題を考えるとバックグラウンド実行も歓迎しにくい

    • 「LocalSendのウィンドウを表示したままアイドル状態だとデスクトップのウィンドウマネージャーがCPUをものすごく使う」って、つまりFlutterらしいという感じ
    • さっきインストールしてみたけど、この種のアプリの中では一番手間のない体験だった
      唯一の不満は、受信側の端末が起きていてアプリが前面にないと動かないこと。少なくともAndroidではクイック保存オプションを有効にしてもそうだった
      Quick Share（旧 Nearby Share）がLinuxでも使えたらいいのに。Chrome経由でも構わない
    • issueとして上げてもらえる？
    • ローカルでのファイル共有用に、こういうクロスプラットフォームで非独占的なソフトウェアは本当に良い
    • アニメーションをオフにすればいいだけ。オンだとCPU使用率が4〜7〜14%くらいだけど、オフなら**0〜2〜3%**程度

  • 少し前に弟と携帯電話の話をしたのだが、彼は仕事の都合でiPhoneを使わなければならない
    米連邦の山火事消防士で、昨夏はずっとホットショットの任務に就いていたのだが、携帯の電波も中央Wi‑Fiルーターもない僻地では、チームが散開する前にAirDropで地図のようなファイルをやり取りしているそうだ
    なかなか興味深いが、このツールもAndroidからiPhoneに送るような状況をサポートできるだろうか？

    • できる

  • プライバシーポリシーが最高: https://localsend.org/#/privacy

    • 「プライバシーポリシーは随時更新される場合があり、変更はこのページに新しいプライバシーポリシーを掲載した時点で直ちに有効になる」という文言は、実際にはかなりよくない条項に見える
    • 利用規約（https://localsend.org/#/terms-of-service）はあまり良くない
      「あなたが18歳以上であることを表明し、当社は18歳未満によるサービス利用を認めない」と書かれている
      家族、特に子どもたちと一緒に使おうとしていたので障害になる
    • 個人情報を収集しないという話以外に、何を共有するのかについての説明がない

  • 2024年になってもAirDropがAppleエコシステムの大きな強みであることには驚かされる
    技術的には可能なものの中でも最も単純な部類の機能なのに、イノベーションは技術ではなく、Appleにはあって競合にはない利害の一致から生まれている
    競合各社は互いに競争しながら、同時にAppleとも競争しているからだ

    • みんながSamsungを使っているなら、全員がQuick Shareのようなものを使えばいい。ロックインは称賛すべきものではない
    • 「技術的に可能なものの中で最も単純な部類」なら、なぜ2台の端末の間で一時的な無線ネットワークをシームレスに作り、本当のP2P高速転送をサポートする自由なオープンソースの「AirDrop代替」が1つもないのだろう？
    • 独占的なロックインのやり方は、CEO Magazineのようなものがあるなら表紙を飾らせてくれるかもしれないが、それはイノベーションではない
      Appleは独自ケーブルへの批判を何年も退けていたのに、EUの義務化後、iPhone 15のUSB-Cポートをこう説明した:
      「新しいUSB-Cコネクタにより、iPhone 15の充電に使うのと同じケーブルでMacやiPadも充電できます。iPhone 15でApple WatchやAirPodsも充電できます。ケーブルの雑然さにさよならを。」
      https://www.apple.com/ca/iphone-15/
      こうしたことが繰り返されるのは、AppleとGoogleがコンピューターと携帯電話の間の機能格差を広げ続けているからだ。携帯電話側では、消費者がサードパーティ製アプリや周辺機器を使う際の選択肢がはるかに少ない
    • 2011年製のSamsungのフィーチャーフォンを引っ張り出してみたら、BluetoothでPCと直接ファイルをやり取りできることを知って驚いた

  • このソフトウェアについては、Techno Timの使い方動画をおすすめする
    利用例を説明し、主要なプラットフォーム全体でデモしてくれる: https://youtu.be/2ITezMkbAqE?si=-YVJq8iqwFYQ9gMr

  • 数か月おきにこういうツールが新しく出てくるが、そのどれも広く使われるには至っていない

    • 2024年なのに、同じLAN内のシステム同士でファイルを送るまともで一般的な方法がいまだにない。インターネット越しとなればなおさらだ
      こうした空白地帯が生まれるのは、解決してもお金にならず、オープンな解決策はいつもそうであるように使いにくいから、というだけではない
      この場合は、解決しないことにこそ金がある。優れていてシンプルで普遍的な解決策があれば、すべてのファイルに対するクラウドのデータマイニングを可能にしたり、サブスクリプションを要求したりする巨大で複雑なクラウドストレージシステムの需要が減ってしまう
    • https://wormhole.app/はかなり良い
    • こうしたプロジェクトにできるだけパッチを送って相互運用性を持たせると有用だろうと思ったことがある
      おそらく、できるだけ多くのアプリに同じプロトコルを実装する形になるだろう
      結局のところ、十分に共通プロトコルが使われて、ほとんどのアプリが互いに通信できるようになって初めてネットワーク効果が生まれる
      もちろん、実際にそこまで深くやる時間や能力が自分にあるかは分からない
    • 「広く」が何を意味するのか分からない。私は https://www.sharedrop.io/ をいつも使っているが、自分しか使っていない

  • LANDropという別のオープンソースプロジェクトを満足して使っているが、
    LocalSendは転送速度が遅いのが気になる。なぜかLANDropよりも遅く、SMBやCrocよりはるかに遅い
    検出にもかなり奇妙な問題がある。自分のiPadからはWindows PCに送れないのに、PCからはiPadに送れる
    サーバーの再起動やファイアウォール無効化などをしても効果はなかった。自分のLANはVLANで少し複雑なので、自分だけの問題かもしれずIssueには上げていない
    ただ、LANDropでは同じ問題がないので、なおさら不思議

    • LocalSendをちょうど設定したところだったが、これを見て考え直した
      2つのGitHubリポジトリを比べると、LANDropはかなり停滞気味に見え、LocalSendは非常に活発だ
      https://github.com/LANDrop/LANDrop
      https://github.com/localsend/localsend
      実際にどれほど重要かは分からないが、考慮する価値はある

  • iPhoneからAndroidベースの車載画面にファイルを送ろうとした経験では、LocalSendとLANDropが最も良かった
    そのほかのSharedrop、Snapdrop、Pairdrop、Arcのようなものは、インターネットが必要だったり、まともに動かなかったりした

  • 検出にはBluetoothが恋しいし、小さなファイル転送でもBluetoothが恋しい
    何らかの形で同じネットワークにいる必要がなくなり、近くの機器を検出できるし、最近ではノートPC ↔ スマートフォン間の転送にも向いている
    大きなファイル転送では、Wi-Fiでアクセスポイントを作ることもできる
    Bluetoothベースの検出がAirDropの強みだ。確信はないが、Appleは大きな転送のために一時的なWi-Fiを作り、相手がそこに短時間接続する仕組みのようだ
    Teleport [1] アプリは検出にZeroconfを使うが、クロスプラットフォーム対応が弱い
    Avahiの設定は複雑で競合も起きるしデーモンも必要なので、おそらくマルチキャストを直接使うほうがよいかもしれない
    付け加えると、Bluetoothにはすでにファイル転送機能（vCardなど）が内蔵されていることを、よく忘れてしまう
    それを表示していたのはGNOMEだけだった記憶があり、しかもNautilus内ではなかった
    WebDAVも似たようなもので、自分にはSMBよりずっとうまく動く。だがほとんどの人はWebDAVが内蔵されていること自体を知らない

    • ランディングページのスクリーンショットは、もっともな理由でAppleを批判しているように感じる
      昨日、友人がiPhone 11 Proから自分のiPhone 15 Proに写真をAirDropしようとした
      端末の上部を合わせると面白い揺れるアニメーションは出たが、ファイルは送信されなかった
      その後AirDropで自分の写真をタップすると、友人側には「確認待ち」が表示されたが、自分側にはポップアップがまったく出なかった
      何度か再試行して再起動までしたが諦め、結局WhatsAppで送った。皮肉にもそれは普通に動いた
      Appleはこうしたバグを直すべきだ。ハードウェアよりソフトウェアへの注力が薄い現状は残念だ

  • クライアント側で何もインストールしなくて済むような、HTTP フロントエンド付きの同等ツールはあるだろうか？
    以前そういうアプリを使ったことはあるが、メンテナンスが止まってもう動かないように思える

    • たいていは Snapdrop(https://snapdrop.net) や PairDrop(https://pairdrop.net) を使う
    • LAN では python -m http.server をよく使う
      元のホストで Python を設定するのが面倒だったり、ネットワークが複雑だったりするなら、転送先ホストで uploadserver[1] を動かすやり方がうまく合う
      名前に「magic」が入った派手なツールが外部リレーサーバーに依存しているのは警戒している
      たとえそうでなくても、古くて単純な HTTP が好きだ。もっと複雑なものは不要で、たいていの場合は暗号化も必要ない
      netcat/socat も解決策にはなるが、Python と HTTP ほどどこにでもあるわけではない。そしてコマンドの呪文をいつも覚えていられない
      [1]: https://pypi.org/project/uploadserver/
    • LocalSend はこれをサポートしている
      https://github.com/localsend/protocol?tab=readme-ov-file#51-browser-url
      それとも HTTP フロントエンドへのアップロードのことを言っていたのだろうか？
    • 選択肢の一つとして https://github.com/akovacs/uploadserver がある。基本的には python -m http.server 8000 のより良い版だ
      まずソフトウェアのあるデスクトップやノートPCでサーバーを1つ立ち上げれば、Webブラウザのある任意のクライアント（Android、iOS、PlayStation、Kindle など）から、クライアントソフトウェアをインストールせずに Web GUI でファイルをアップロードまたはダウンロードできる
      x86-64 Linux、Windows、Mac OS 向けのビルド済みバイナリは https://github.com/akovacs/uploadserver/releases/ で入手できる
      Apple Silicon 向けのビルド済みバイナリはまだないが、需要が十分あれば追加されるかもしれないし、必要なら nightly Rust ツールチェーンでソースからコンパイルすることもできる
      クラウドサービスや python -m http.server 8000 と比べると、このサーバーは Rust で書かれていて非常に高速で、かなりシンプルで（コンパイル後に strip したバイナリは通常 3MB 未満）、すべてをローカル LAN 経由で転送する
      4GB を超える大きなファイルもかなりうまく扱えるようで、ソフトウェアをインストールするのは1台だけで済む
      詳細は https://news.ycombinator.com/item?id=39665095 を参照
    • これを作っている: https://github.com/pvik/simple-file-server/releases