From sjenkin at canb.auug.org.au Sun Apr 4 01:25:29 2021 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Sun, 4 Apr 2021 11:25:29 +1000 Subject: [clug] Wormhole.app: Browser based, "Simple, private file sharing", end-end encryption. 5GB uploaded for 24hrs, 5-10GB peer-peer Message-ID: <4E08188D-680C-4B33-92E8-6DE5603E9EAE@canb.auug.org.au> While its built on open source, they?re keeping the web-client & server code their own, which is sensible. It was only released a few days ago, so very early days. No monetisation model yet. The authors are experienced & capable open-source developers. Seems Javascript is their thing. ======== Simple, private file sharing Wormhole lets you share files with end-to-end encryptionand a link that automatically expires. So you can keep what you share private and make sure your stuff doesn't stay online forever. Security page Twitter John Hiesey Feross WebTorrent Desktop Whether it's video from the Internet Archive, music from Creative Commons, or audiobooks from Librivox, you can play it right away. You don't have to wait for it to finish downloading. ======== Show HN: Wormhole ? Simple, private file sharing (wormhole.app) Just skimming it and it seems cool. What's the max file size? reply feross 1 day ago [?] For files up to 5 GB, Wormhole stores your files on our servers for 24 hours. For files larger than 5 GB, Wormhole uses peer-to-peer transfer to send your files directly from your browser to the recipient. So you'll need to keep the page open until the recipient downloads the files ======== what was the trickiest part to build? reply feross 2 days ago [?] We went to absurd lengths to make Wormhole fast and performant, without sacrificing security. All of the technical challenges we faced came from trying to accomplish these two goals simultaneously: - Build the absolute fastest way to send files - Deliver end-to-end encryption without any compromises Here's a bit more of the technical details: We use streaming encryption (specifically, the Encrypted Content-Encoding standard also used by the now defunct Firefox Send) so that we can keep memory utilization flat, no matter how large the file. Then, we take the end-to-end encrypted file data and simultaneously stream it to browser storage and our servers. When a downloader shows up before the file is fully uploaded, we use the browser copy of the data to stream your files to the downloader directly. This means that they can start downloading even before the files have been uploaded. For the direct peer-to-peer transfer, we use the WebTorrent protocol (which I created). All file data is end-to-end encrypted before leaving the device. It's encrypted yet again in transit by TLS or WebRTC, and also while at rest on our servers. We use a combination of browser storage options, depending on which is fastest and the amount of available disk space. We choose from the following storage strategies: - Storage Foundation API (fastest performance, experimental API, Chrome only for now, https://github.com/fivedots/storage-foundation-api-explainer) - Filesystem Access API (extremely fast, Chrome only, other browser vendors have expressed interest, https://wicg.github.io/file-system-access/) - Cache API (pretty fast, wide browser support, comes from the Service Worker spec, https://w3c.github.io/ServiceWorker/#cache) - Indexed DB (slowest option, wide browser support, https://www.w3.org/TR/IndexedDB/) - In-memory storage (fastest performance, high memory usage (obviously), used as a fallback when disk is full or in private-browsing windows where storage is limited) The browser has become so powerful ? with WebAssembly and powerful new browser APIs ? that we think it's time to use some of that power to make web services more private and secure. It's a lot more work to build a service this way than the normal way, but we think it's worth it. ======== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin