Show HN: I built a website to share files and messages without any server

Original Article ↗ Hacker News Discussion ↗

P2P Architecture and NAT Traversal

  • Tool is built on WebRTC (and PeerJS) with STUN servers for ICE candidate discovery and connection brokering.
  • TURN is explicitly not used; if NAT traversal fails, the app shows an error instead of relaying via a server.
  • Several commenters stress that some centralized infrastructure (STUN / signalling) is unavoidable for most NAT’d users.
  • There’s debate over whether “P2P without server” is accurate when STUN / signalling servers are still required.

Encryption and Security Model

  • WebRTC’s built‑in DTLS/SRTP encrypts transport; there is no additional, application‑layer file encryption.
  • Some commenters argue that transport‑level encryption alone is not “end‑to‑end encryption” in the strong sense, since the signalling layer can be a MiTM and app‑layer keys are not independently managed.
  • Suggestions are made to add client‑side crypto (e.g., WebCrypto‑based libraries) to achieve real E2E.

“No Server” Claim and Trust Model

  • Multiple comments challenge the marketing claim “without involvement of any server” and “bypassing centralized servers.”
  • Points raised:
    • The web app itself is served from a centralized host and could be modified at any time to exfiltrate data or weaken crypto.
    • Different users could be served different JS bundles, making auditing difficult.
    • Even if the author is trustworthy now, ownership or intent could change.

Web vs Native Security Discussion

  • Some argue web apps are safer due to sandboxing and strong browser dev tools.
  • Others counter that native apps benefit from code signing and more stable integrity guarantees, while web apps require renewed trust on every load and rely on a complex CA/hosting ecosystem.

Comparison to Existing Tools

  • Many similar WebRTC P2P file/message tools are cited: Pairdrop, Snapdrop, Sharedrop, FilePizza, Wormhole variants, Webwormhole, Sendfiles, etc.
  • Non‑WebRTC / non‑browser tools such as Syncthing, KDE Connect, Magic Wormhole, croc, woof, and FileBrowser are also mentioned as alternatives with varying UX and trust properties.
  • Several commenters question what meaningful differentiation this project offers.

Open Source and Adoption Concerns

  • Initial skepticism over closed source and the author’s other data‑accessing extensions leads to “red flag” comments.
  • The source code is eventually published on GitHub, but concerns remain about vague/weak encryption claims and the general trust model.