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

Original Article ↗ Hacker News Discussion ↗

A new web-based tool claims to let users share files and messages peer‑to‑peer without servers, prompting scrutiny of how “serverless” it really is given its reliance on WebRTC, STUN infrastructure, and centralized hosting of the JavaScript client. Commenters question the security model, noting that transport‑level encryption (DTLS) is not the same as end‑to‑end encryption and that the hosting server could silently change the client code, while also comparing the project to established open‑source alternatives like Snapdrop, Pairdrop, Syncthing, Magic Wormhole, and file.pizza. Concerns about transparency and trust—especially around encryption, NAT traversal, and the anonymous nature of the developer—lead to strong calls for open‑sourcing the code, which the author eventually does.

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.