Hey! Blip co-founder here. We didn't expect to show up on HN, but really grateful to OP for sharing Blip. Here's a little bit more about it.
We've built Blip because it's still hard to send original quality photos, videos, and large files to your devices and to other people on the internet. We’re designers and engineers, so our goal has always been to keep the product super simple on the surface, but really fast and powerful underneath.
Blip works in a peer-to-peer way at the UI level: you pick the device or person, and Blip takes care of the delivery. Transfers go directly over WAN whenever possible, and fall back to relays when needed. The idea is to send in one click, skipping the usual dance of moving files through cloud drives and managing shared links.
Under the hood, Blip is optimized for large media and data transfers. It supports full-speed acceleration, resumable progress, and we're rolling out E2EE across all clients to ensure sensitive business data remains secure. Many creative pros and teams already use Blip in their daily media workflows.
We don’t monetize data because it doesn't align with the values of our creative and technical users. Instead, we run on a simple donation and subscription model that lets you support the product and use it without limits, quotas, and frustrations. Our goal is to make file transfer feel invisible.
Thank you, and great question. In my experience, big companies have way more strategic priorities than two guys who just want to build something useful. We didn't leave to build exactly this, but a few things came together organically from past projects, including our work at Dropbox.
That's right. We actively manage load across our relay network to ensure good performance, but we'll prioritize business transfers during peak times. We don't artificially limit the client, but P2P connection speeds can sometimes be affected by router configurations and ISP routing. For example, some ISPs route P2P traffic through slower paths, which can introduce variability.
We evaluated QUIC (and many other approaches). Turns out it's a lot harder than you might think to move traffic at high speed across the world, over residential-grade internet, and not drain your battery.
If it's truly p2p, some relay would be there in case the client cannot be reached through NAT. Not sure how they would bear the cost of the bandwidth for unlimited transfers in that case
I wonder how widely usable is file sharing nowadays when most of the non tech people just use cloud services for their data, be it google docs or some cloud photo storage
Most non-tech people do not just use cloud services for their data.
Really not sure where you got that from, but even if it was true, most non-tech people will still shy away from putting a 250G file in a cloud service once they get prompted to upgrade their plan because they don't have enough space.
I dunno, seems like most do? Their stuff is in Google Photos, Google Docs, iCloud Drive, etc. And yes they pay for the space once their photos or phone backups get big enough.
And I don't know any non-tech people who have any 250GB files. The only people I know with those shoot 4K video professionally. Or scientists running truly massive simulations.
I think non-tech people used to be able to, but tech companies have been on a 10+ year long crusade against the concept of a "file" and where that file is "stored" and trying to blur once-sharp lines so that people forget. Tech really wants you to think of your data as an amorphous blob vaguely "in their app" and not worry about crisp delineations like files, whose hard drive those files are on, and whose machine that hard drive is in.
Who else needs to share files bigger than 1 TB? Most cloud services, such as Google Drive or OneDrive, are more than sufficient for managing massive files. I don't see the appeal of this new service.
Oddly enough, I would argue the exact opposite direction; really big files are exactly where I want to do a direct p2p transfer without paying to store it in the cloud.
Readit News
We've built Blip because it's still hard to send original quality photos, videos, and large files to your devices and to other people on the internet. We’re designers and engineers, so our goal has always been to keep the product super simple on the surface, but really fast and powerful underneath.
Blip works in a peer-to-peer way at the UI level: you pick the device or person, and Blip takes care of the delivery. Transfers go directly over WAN whenever possible, and fall back to relays when needed. The idea is to send in one click, skipping the usual dance of moving files through cloud drives and managing shared links.
Under the hood, Blip is optimized for large media and data transfers. It supports full-speed acceleration, resumable progress, and we're rolling out E2EE across all clients to ensure sensitive business data remains secure. Many creative pros and teams already use Blip in their daily media workflows.
We don’t monetize data because it doesn't align with the values of our creative and technical users. Instead, we run on a simple donation and subscription model that lets you support the product and use it without limits, quotas, and frustrations. Our goal is to make file transfer feel invisible.
Happy to answer any questions.
Maybe they just mean if you end up with a relayed connection due to NAT issues? Because lower down it says "Send as fast as your connection"
We evaluated QUIC (and many other approaches). Turns out it's a lot harder than you might think to move traffic at high speed across the world, over residential-grade internet, and not drain your battery.
https://www.iroh.computer/
[0] https://github.com/n0-computer/sendme
[1] https://magic-wormhole.readthedocs.io/en/latest/
[1] https://syncthing.net/
https://send.drexl.dev/
or tailscale's Taildrop as a native application: https://tailscale.com/kb/1106/taildrop
Dead Comment
Android: Wormhole William (https://github.com/psanford/wormhole-william-mobile)
iOS: Destiny (https://github.com/LeastAuthority/destiny)
Some drawbacks to my current approach:
1. Destiny needs to be configured to use the standard Magic Wormhole servers (just once, after installation): https://github.com/LeastAuthority/destiny/issues/259#issueco...
2. Initiating a transfer requires out of band communication and some copy+paste.
Really not sure where you got that from, but even if it was true, most non-tech people will still shy away from putting a 250G file in a cloud service once they get prompted to upgrade their plan because they don't have enough space.
And I don't know any non-tech people who have any 250GB files. The only people I know with those shoot 4K video professionally. Or scientists running truly massive simulations.