Peer-to-peer file transfers in the browser

Original Article ↗ Hacker News Discussion ↗

Reliability and usability of browser P2P tools

  • Many commenters like the idea of WebRTC-based browser‑to‑browser transfer but report frequent failures, especially for large files or across varied networks.
  • Some say they have never seen these tools (FilePizza, ShareDrop, etc.) work reliably, even on LANs.
  • Others note that needing to keep a browser tab open is a practical drawback vs. dedicated clients.

Local discovery, offline use, and signaling

  • A major pain point: lack of local peer discovery in browsers. WebRTC typically needs an Internet connection plus a shared identifier/URL.
  • People discuss QR codes, audio, Bluetooth, NFC, and manual copy-paste as ad‑hoc signaling channels.
  • Browser‑to‑native (e.g., WebRTC + mDNS via a local app) is possible; true browser‑to‑browser offline discovery is seen as blocked by privacy/fingerprinting concerns.

Security, privacy, TURN, and trust assumptions

  • Several comments dispute the claim “no intermediary server,” pointing out that signaling and often TURN relays are involved.
  • Clarifications:
    • STUN helps NAT hole punching; TURN relays traffic when p2p is impossible (e.g., symmetric NAT, CGNAT, mobile networks).
    • With TURN, traffic can be relayed; DTLS/WebRTC encrypts packets, but a malicious operator who controls both signaling and JS can still MITM by swapping keys/clients.
  • Some argue they disable TURN to avoid relay risks, accepting that some connections will fail.
  • Others emphasize that serving JS from a third‑party site always requires trust; self‑hosting is the only way to be confident.

Ownership changes and erosion of trust

  • Strong concern over LimeWire acquiring popular FOSS web tools (ShareDrop, Snapdrop).
  • Users feel betrayed after recommending such tools for “local, private” sharing and later discovering files go via a new corporate backend.
  • This leads some to vow self‑hosting or using packaged apps only.

Alternatives and fragmentation

  • Long lists of alternatives are shared: Magic Wormhole (+ Go impl), croc, webwormhole, wormhole.app, OnionShare, iroh/sendme, PairDrop, keet/holepunch, WeTransfer, Syncthing, FTP/HTTP ad‑hoc servers, copyparty, Galene file transfer, blip, etc.
  • Confusion is common because similarly named tools (wormhole.app vs. magic‑wormhole vs. webwormhole) are unrelated.

Lack of standard, cross‑platform “AirDrop”

  • Many lament that in 2025 there is still no simple, standardized, secure, cross‑platform file transfer akin to AirDrop.
  • BitTorrent/IPFS are cited as underlying tech, but seen as too heavy or user‑unfriendly for casual one‑off transfers.
  • Commenters blame NAT complexity and, more importantly, platform lock‑in incentives from Apple/Google and the “copyright cartel” chilling easy sharing.

URLs, UX, and CLI integration

  • People complain about long, awkward URLs; they prefer short, phone‑readable room codes (PairDrop gets praise here).
  • A specific “holy grail” use case: start a transfer from CLI, get a short URL, recipient just uses a browser, and transfer streams without full pre‑upload. Some tools approach this but with tradeoffs around encryption and trust.

WebRTC/NAT technical debates

  • Thread goes deep on symmetric NAT, CGNAT, STUN vs TURN behavior, and the rarity vs prevalence of environments where pure p2p fails.
  • Some regions reportedly see WebRTC almost never work due to ISP setups. Lack of browser support for PCP/UPnP is criticized.

Ecosystem, nostalgia, and implementation choices

  • References to xkcd #949 (“file transfer hell”) and #927 (too many standards) recur; this space is seen as highly fragmented.
  • Nostalgia for older solutions: netcat, sneakernet, floppies, early Opera Unite with built‑in P2P, old Java applets.
  • Some question whether tools like FilePizza really need React/Tailwind/TS for a relatively simple function.

Naming concerns

  • Multiple comments note that “filepizza” inadvertently overlaps with disturbing slang (“cheese pizza” for CSAM) and prior notorious nicknames, calling the name extremely unfortunate.