Blip: Peer-to-peer massive file sharing(blip.net) |
Blip: Peer-to-peer massive file sharing(blip.net) |
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.
or tailscale's Taildrop as a native application: https://tailscale.com/kb/1106/taildrop
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.
Like Apple offers this for email for iCloud users. I think Firefox Relay offered it too. There was another company in the late 00s that offered a P2P version.
I mean _cool_, but I’ve not seen a company with this as its primary product last more than 18 months before. With that, _good luck_.
> How is Blip different to nearby sharing like AirDrop? Apple’s “AirDrop” and Google’s “Nearby Share” can be really handy. However, they aren’t compatible with each other and require devices to be physically next to each other. They are also unreliable when transferring large files, and will often lose your progress.
> Blip doesn’t need devices to be nearby, so it’s much more reliable. Blip works wherever your internet connected devices are in the world, and works regardless of what kind of device you own. You can transfer from Android to Mac, Windows to iPhone, iPad to Android—you name it!
AirDrop is for people who are physically nearby.
This allows to send files between any computers anywhere.
The other person must be a known contact but it doesn't have to be on the same local network like in AirDrop.
> at super fast speeds
Fast speeds aren't a thing, just like cheap prices and wet waters aren't.
Fast means "of a high speed", so it's the same here.
J/k
It's a high quality nit pick imo:)
The product looks polished and I definitely see myself using it. My only concern is: Are they taking VC money? Is this going to be enshittified to death trying to pursue a 1000x investment return?
1. For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.
2. It doesn't actually replace a USB drive. Most people I know e-mail files to themselves or host them somewhere online to be able to perform presentations, but they still carry a USB drive in case there are connectivity problems. This does not solve the connectivity issue.
3. It does not seem very "viral" or income-generating. I know this is premature at this point, but without charging users for the service, is it reasonable to expect to make money off of this?
It worked out the first time!
Not sure why this needs to be a service. Or why data needs to go through their servers.
but yes, sure sounds like it!
2. - nothing would by your criteria of an airgap, that's a strawman, this is just an alternative over the wire method (as is bluetooth file transfer)
Now let see if the founder(s) will reply here and to run it all back from start to IPO.
What would the founders do differently from dhouston this time?
I don't think the word "trivially" means what you think it means.
[Edit: I now realize the above is a verbatim quote from a naysayer after the Dropbox announcement]
You cut off "for a linux user [in 2007]" and that's a very important part of the sentence.
...
this is hardly the same thing?
It's not a good solution to send individual large files.
In a previous life, I used Syncthing to transfer terabytes of files from the company I worked for to a third-party printer. It was delightfully reliable, and easy to set up.
If it's a one-off, yeah, you're right that it's not wonderful. I've used Magic Wormhole successfully for that use case.
Trust not only they are not malicious, but also they won't have some kind of vulnerability.
Plus if it's encrypted how is the other party going to read the file? The key will have to take the same path.
Wouldn't that still be the case if relay servers didn't exist? A hacked version can send your file to the wrong person.
How do those 2 programs find out about each other?
Well, they need to use some server that will connect all users, allow you to find the other person in order to send them a file.
Even BitTorrent needs tracker servers to connect downloaders to uploaders.
Now, you could try to make it run without a company behind it, like BitTorrent.
I guess it's an exercise for the reader.
Someone still needs to run those connecting servers out of the goodness of their heart.
You would need to degrade the usability (the first thing a user would need to do is to configure the app with the address of at least one connecting server).
BitTorrent is anonymous but for sending files you need to connect to a person you know. If you enable contacting via the protocol, it'll be a phishing nightmare.
So you'll have to degrade usability some more and use a side channel (e.g. an email) to exchange identities with people you want to send file to (or receive files from).
By having a service and a company behind it, they are able to perfect the UX and run the necessary servers to implement that UX.
Magic Wormhole is cool (I just learned about it! Thanks! :)), but most people don't use nor care about the command line, and are probably afraid of it.
The vulnerability doesn't even have to be in their software, but in any piece of software they use, ssh, nginx, etc.
A meaningful vulnerability would have to be in either the software itself or in the coordination server. That attack surface is the same whether or not you have relays.
You can reduce the attack surface to just the software if there's a way for users to verify keys manually. But again, same attack surface whether or not you have relays.