I keep a long list of browser based and CLI p2p file transfer tools[1].
LimeWire (which now has its crypto currency probably) has been on a rampage recently aquiring some of really good tools including ShareDrop and SnapDrop. https://pairdrop.net/ is the last one standing so far.
Probably you can also add Dragit[1], which is a desktop p2p file sharing tool for local network with automatic host discovery. Currently supporting Linux and Windows. (author & maintainer here) I'm not sure if I should keep on working on the tool, considering the length of the list so far. :D
Both not to be confused with Web Wormhole, which is also pretty good: https://webwormhole.io/
Slightly different approach – "P2P first", i.e. both sender and receiver need to be online simultaneously throughout the transfer, but there's a TURN relay, so it should work in almost all network constellations.
My previous company used WeTransfer a lot, because we needed to send large filesystem images and Android releases to and from China, and the great firewall hobbles obvious things like using gdrive.
Opera browser used to have P2P file transfers as a short lived feature in ~2010, called Unite. I remember it also had skeuomorphic GUI of a 'fridge' where users could put post-it style notes that could be seen by others.
One of many everything-and-the-kitchen-sink features Opera Presto had during its heyday. Others included a separate Bittorrent client, desktop widgets that could be moved outside of the browser window, full IRC client, email client and peerless hotkey actions customization.
By some miracle the browser still managed to be a rather lean binary.
We did not decide it. Google decided to kill it. In countries where Opera had major share Google ran aggressive and deceptive (something something faster) campaign with billboards, radio and tv ads. Chrome ads were also everywhere on their homepages (google.com, youtube.com).
But more nefariously, Google kept blocking features and apps based on the UA agent alone. Add lots of tech demos with their custom extensions.
Don't forget bundling Chrome with random apps (I remember cCleaner), making it install silently and automatically set itself as default.
I got caught by this as a kid a few times, I was technical enough to know what was going on, and reliant on a screen reader (which Chrome didn't support back then), so it was definitely a memorable annoyance for me, but I guess quite a few people didn't care.
Do you mean Opera Unite, that had p2p file sharing and a 'wall' (I think it was termed the fridge door, all your verified users could leave you notes/images on it IIRC).
Vivaldi is roughly 1000 times slower. You need a pretty good computer to run that UI. It also lacks extremely basic features Opera had; like working LRU tab switching. I liked the idea, but it's impossible to recommend.
Is that true? I remember having to change a setting to switch the behavior of tab switching because it was LRU by default and I prefer it in visible order.
It used to work and broke maybe 2 years ago. This tells me that no one is actually using the browser and that no one is really working on it either. It receives chromium updates and then some money-making features here and there.
It's been a while, 8-10 years ago maybe? But quick look now tells me it's still one person effort. That's both awesome and unfortunate. I wish it got more traction back then to attract more active user/dev base.
I remember M2, their mail client, which had good "AI" auto labelling of e-mails. For today's standards probably not outstanding, but back then it worked nicely, and I wish I had something like it for Thunderbird, but so far any plugin to auto label anything in Thunderbird has failed me. Thunderbird needs tagging to improve and be better accessible.
I really wished opera had a greater market share than it did. It did relatively well for a few years with share between 1-4%. But was lagging behind defunct browsers like IE6. And back then the browser space was only chrome, Firefox, and IE. Notable mention to safari and KDE fwiw.
The everything browser made it a difficult experience to understand. Kind of a feature overload in the face of minimalism being practiced by chrome and ie7.
Someone made a torrent website software for it which spawned something like 50 good torrent websites. Combined with the build in torrent client and irc client it made a wonderfull experience.
The thing that usually annoys me about these services is they tend to give you an intractably complex URL to share with the recipient. This poses a problem because every time I need such a P2P transfer, I’m communicating with someone over the phone and they need the file on a computer (which may not even be their own, so email is also cumbersome).
https://file.pizza does this better than most, as the URL consists of real words. But all the words are ingredients in English which comes back to being an issue again.
https://pairdrop.net is my go-to, since it allows creating temporary “rooms” with just five letters, which are easy to share over the phone.
Still, I continue to wait for the holy grail of a P2P service which would allow me to initiate a connection via CLI and get a simple URL to share with someone who could download the file from a web browser, saving me from having to babysit the browser tab. There are services which allow you to upload via CLI and download via web browser, but they host your file so you have to wait for the full upload to finish before sharing the link.
One tricky constraint is that a "simple URL" isn't big enough to hold a full-entropy encryption key. So your security must either come from PAKE (like magic-wormhole and friends), or from the good behavior of some intermediary. And PAKE requires a peer who knows the plaintext and will only execute the protocol once, which means it really needs to be the person you're connecting with and not an intermediate webserver.
I think it's a 2-out-of-3 trilemma: end-to-end encryption, short codes/URLs, offline/non-interactive workflow: choose two. Or framed differently, if you require proper encryption, then either the code/URL must be long enough to hold the full key, or you must use an interactive (PAKE) protocol which means both agents must be running at the same time (babysitting).
Your last point is an interesting one: we could build a form of magic-wormhole where the sender's CLI waits, the recipient gets a URL, the URL points to a web page which performs the client side of the protocol. The server wouldn't host the file, just the decryption agent. Basically wormhole receive in a browser. That would match many of your goals.
However I'd be hesitant to do this with magic-wormhole because it opens up a vulnerability we don't currently have: the web server hosting that page could silently swap out the JS with a version that retained a copy of the plaintext, perhaps only when the browser is coming from a specific IP. You can't audit a webserver for consistent+correct behavior the way you could with e.g. the contents of a Debian distribution.
That said, the usability gains of the recipient not needing a CLI tool installed might be worth the tradeoff for some folks.
> a "simple URL" isn't big enough to hold a full-entropy encryption key.
I don’t care about that most of the time. When I do I’m unlikely to trust some random web service anyway (how do I know the author didn’t turn rogue the day before and decided to send a copy of every file to their own server?).
The service could offer a choice, where picking the short link comes with a big red warning. That could even be hidden under some setting on the page, since it’s the sender who needs to understand the implications.
> the usability gains of the recipient not needing a CLI tool installed might be worth the tradeoff for some folks.
That’s exactly what I’m looking for. Whenever I need one of these services, there is 0% chance the person on the other side would know how (or have the patience) to install a command-line tool.
> I'm the author of magic-wormhole
Thank you for taking the time to expand so thoroughly from experience.
> One tricky constraint is that a "simple URL" isn't big enough to hold a full-entropy encryption key.
If you trust the server not to MITM you, then you don't need the encryption key in the URL. The URL only needs to be long enough so it cannot be guessed by an attacker, 64 bits should be plenty. Once the peers connect to the common URL, they can generate an arbitrarily large key by performing ECDH through the server. (This is where you assume that the server is not doing MITM.)
> the holy grail of a P2P service which would allow me to initiate a connection via CLI and get a simple URL to share with someone who could download the file from a web browser
git clone https://github.com/jech/galene-file-transfer
cd galene-file-transfer
go build
./galene-file-transfer -to john https://galene.org:8443/group/public/somethingdifficulttoguess/ file.tar.gz
> There are services which allow you to upload via CLI and download via web browser, but they host your file so you have to wait for the full upload to finish before sharing the link.
There are exceptions to this; I've been making copyparty[1], an httpd which lets you start downloading a file that is still being uploaded[2]. If you catch up with the uploader, it'll throttle the speed so the browser doesn't drop the connection. Uploads and downloads can be done through browser and/or cli.
I recall there was at least one other alternative with similar functionality somewhere on the awesome-selfhosted list, but I'm failing to find them right now... It was prominently mentioned in the project's readme, but maybe that's no longer the case.
Unfortunately this seems like it’s something I’d need to host myself, and that’s something I specifically don’t want to do. I only need to share on occasion, and always want to do it with the least hassle possible.
Yep, and the server bandwidth can become a bottleneck if the peers are fast enough, so true peer-to-peer is still the better choice, or something webtorrent-based if multiple people are grabbing the same file.
But there's been enough last-minute submissions of DJ material by now that I'm still happy it was added as an option :-)
That’s a lot of red! I didn’t know about this one, thank you for the share. I suspect I still won’t use it over PairDrop because the web page is too busy, the “Check out my other projects” completely draws the eyes, and I want something that’s clean and not distracting for the receiving end.
It wasn’t the lack of commits which made me think this was abandoned, but everything else (outdated instructions, issues and pull requests open with no reply, giant warning at the top of the README…).
If it were completed, the author should have closed/rejected every issue and pull request and removed this large warning at the top of the README:
> THIS PROJECT IS STILL IN EARLY DEVELOPMENT IT USES EXPERIMENTAL
CRYPTOGRAPHIC LIBRARIES AND IT HAS NOT HAD ANY KIND OF SECURITY
OR CRYPTOGRAPHY REVIEW THIS SOFTWARE MIGHT BE BROKEN AND UNSAFE
Plus, install instructions are outdated. As soon as I tried them, `go` complained of using a deprecated method.
So everything points to it no longer being under development.
Not much development can be done about experimental cryptography, you just use it and that's all. Cryptographic review can't be written either. Also you said you don't want much cryptography.
> Not much development can be done about experimental cryptography
That’s not the bit that matters, it’s the “this project is still in early development” and “this software might be broken”. Those are the things which hint at the project not being done.
That is the opposite of what I want, everything about it is harder to share over the phone. Magnet links are not exactly short and now I’m asking people to install a BitTorrent app too, on a computer which might not even be theirs.
The file.pizza one doesn't look like it's peer-to-peer. You upload a file to their server, and then they provide a download URL you can share. Kind of the opposite of peer-to-peer. I would expect a "P2P" file transfer product to not require any intermediate storage besides the sharing user's and the recipients'.
I wish there was a way to do local peer discovery with WebRTC. Right now both endpoints need an active Internet connection and a shared identifier (in this case a special URL) in order to find each other. Can't do offline local sharing.
If one end of the connection is a native app like this you have plenty of other options. Browser to browser is the use case I'm talking about.
It could be done with a browser-owned dialog to select peers instead of exposing all local peers to the web by default. Similar to the web MIDI API or others that expose local devices only with explicit user permission for the specific device.
I solved this issue by implementing a webtorrent tracker[1] client. Signalling server is still needed, but with this approach any webtorrent tracker can act as one.
Sharing identifier maybe we could do with qrcode, chirp audio protocol, nfc tap. Ios has peerconnectivity that works really as p2p network but sadly no web api and doesn't work android (not sure someone reverse engineered protocol)
Somebody indeed has, but since it uses a custom low-level 802.11 variant, I don't think it's feasible on (at least non-rooted) Android devices: https://github.com/seemoo-lab/opendrop
> Because data is never stored in an intermediary server, the transfer is fast, private, and secure.
But WebRTC needs a TURN server for when hole punching/STUN doesn't work when both clients are behind NAT.
Data is never stored in an intermediate server, but it can pass through.
How is the privacy and security ensured that the TURN server won't/can't read your data? Do you just have to trust them? Or is a form of E2EE employed?
I'm surprised this isn't even metioned on the page. Or does this not include TURN servers, and so file transfers just fail between certain peers? (Which it doesn't mention either.)
WebRTC, in fact, merely passes e2e encrypted packets through the TURN server (which, by the way, is only required if both sides are behind symmetric NAT: the vast majority of NAT doesn't cause this problem, though you might need to do STUN).
A lot of cell networks won't work with STUN. I've tried in personal projects to have a home computer with wifi communicate through a stun server to a mobile device using mobile data. It don't work.
> the vast majority of NAT doesn't cause this problem
A WebRTC clients behind an iptables based MASQUERADE NAT will not work without TURN. Which both incredibly common and weird that people designing WebRTC and STUN/TURN/ICE never stopped by netfilter developers to make iptables work out of box with WebRTC.
Hmm. I'm not a WebRTC pro but looked into it recently for a hobby project and felt that the typical WebRTC TURN implementation still leaves the TURN server in a quite trusted position. My rough understanding:
- (1) Each client generates a key pair
- (2) The fingerprint of the public key is part of the SDP message each client generates
- (3) The SDP message is somehow exchanged between the clients, out of band, and the session is started. The client's verify the remote peer using the public key from the SDP message.
The problem is that it's not really feasible in most circumstances to exchange the full SDP message out of band, so instead the service provide some mechanism to map a shorter ID (typically in a URL) to a centrally stored copy of the SDP. I think this might be where it happens for filepizza [0].
This means that a malicious file sharing operator, being in control of both the TURN service and the out-of-band signalling mechanism, could just MITM the DTLS connection and snoop on all the data going by. The peer's think they have each others public keys but they just have two keys owned by the server.
Only the initial SDP needs to be fudged. The attacker could just set up two clients that pretends to be the sender/recipient. Then the data can just go through regular Google TURN servers.
That's incorrect. What you're describing is STUN, when it works. TURN is what is used when peer-to-peer remains impossible. All data transfer is via the TURN server.
Both clients send a packet to a server, server sends the remote IP to both parties, both parties try to send traffic to either’s remote IP. Unless their nat firewall is evil, this should work.
That doesn't work with "symmetric" NAT, which was specified by the person you are responding to: in that case, you can't rely on even a third party to figure out the port. To the extent to which this NAT paradigm is chosen for its efficient usage of ports, this is fixable using UPnP/NAT-PMP/PCP, but 1) I've (sadly) never seen a WebRTC implementation which takes advantage of these protocols, and 2) usually this isn't chosen for it's port efficiency: it is chosen because the NAT provider is incompetent (or even actively "evil", lol), and so they are almost certainly also not going to support a port mapping mechanism.
Regardless, I'll claim that the real disagreement is more over how common symmetric NAT is: I claim it is very rare, and that the vast majority of NAT isn't symmetric... however, in another thread, the user you are responding to claims that "in [their] country" they've never seen WebRTC work at all. I'd wager that's a pretty local issue, with what probably amounts to a local oligopoly built with similar limitations, but if you live in that world it must be brutal. However, that's not WebRTC's problem: we should implement port mapping in clients and ISPs should, to put it as kindly as feels fair, "fix their shit".
> A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port.
My understanding is that it's not "required", but most of the CGNAT routers I've encountered do symmetric NAT, and they force-randomize the source port for each new connection, then keep it fixed for one external ip:port for some "session" duration, defeating traditional hole-punching.
When I've tried to build WebRTC P2P stuff I've experienced this making direct P2P WebRTC connections between CGNAT users nearly impossible, always requiring at least one node with a re-usable hole-punched public udp port or a relay server.
Such CGNAT should also be more likely to support PCP than a normal NAT. It does suck that, AFAIK, no browser has integrated support for this into their WebRTC stacks :/.
Wow, as someone who worked at the original limewire back until we got sued out of existence, this makes me sad to hear some scammers bought the IP and resuscitated the corpse of the company.
Yup. I recommended snapdrop to everyone in my family and friends for local data sharing without a cable.
When I discovered that it now uploads stuff to Limewire I was so annoyed that I had to admit I suggested a harmful tool for sharing private data.
So much, that I will never recommend a similar website. Either I'll host it my self or suggest an installed tool through F-droid, if it exists.
I mean, it is entirely my fault. I knew the security risk, but set it aside, because I didn't think some known guy developing an open source tool would in his name try to grab your data.
It's so strange that this should have been a solved problem decades ago, but somehow a robust and secure non-commercial solution never gets off the ground.
Speaking of which, how is the IPFS project doing these days?
Peer to peer sharing doesn't really have much opportunity for commercialization. The closest thing I can think of is bluetooth file sharing, which can still be a painful experience in some circumstances
Yes businesses tend to only work on interoperability when the interoperable product is just a complement to their main revenue generator. Like how Netflix releases clients for many platforms. No one is going to be motivated to make a (1) free (2) easy to use (3) cross platform file sharing solution. It'll also draw the ire of the copyright cartel. File locker websites have been harassed and "legitimate" cloud storage services are forced to police their user's files.
I think people mean something seamless like AirDrop is on Apple devides, but some public standard that gets implemented on all platforms like iOS, Android, Windows, macOS and Linux, so all these platforms can just easily send files to each other simply and securely over WiFi.
> I think people mean something seamless like AirDrop is on Apple devides
Ha! I do wonder if I'm the only person who has errors where sometimes an AirDrop attempted transmission, from two devices sitting right next to each other, just hangs indefinitely, even if a transmission between the same two devices a minute ago succeeds. Like all Apple solutions that Just Work, it's great when it Just Works, but, when it doesn't, great effort seems to have been taken to make sure that there's no way to find out why not.
Torrents can be seamless. I take it you haven't used a download manager that would just grab any file, treating torrents just like any other download, as seamless as HTTP downloads are?
It doesn't have to be a dedicated system where you manage how long you seed, port forward, and other technical requirements: torrents already work well when you just seed while downloading because the server can never get overloaded, pretty much no matter how viral something goes. So long as it keeps serving the tiny torrent file, a few blocks on occasion, and the few packets needed to set up a NAT punch between people (STUN/TURN server? I always forget what's what), people can get the file from each other and you don't have huge bandwidth costs or have the site go down once the included bandwidth is exhausted. There's a reason Facebook and Twitter use(d?) this for distributing server updates¹, and I don't think someone remotes onto every server to visit the pirate bay, which torrent technology has sadly become synonymous to and people don't realise it is a transfer protocol just like FTP, HTTP, and other TPs that I'm forgetting
> some public standard that gets implemented on all platforms
What this is based on doesn't matter. It can be http, it can also be torrents. It's not very useful if you're sending files from and to one person almost every time (perhaps at the end of a holiday with friends, more than one person would want everyone's photos, but still), I'm just objecting to torrents being misunderstood as the only thing most people used it for: downloading copyrighted material in dedicated (and often unwieldy) software :)
There’s no incentive for big players to play nicely with other platforms so they just won’t. Hardware standards like Qi2 are different since it affects costs directly. Software is usually built for lock-in since quite some time.
“Buy your mom an iPhone” and how Apple buried beeper mini into nonexistence was a nice example.
"Securely" is doing a lot of work here; you need some out of band mechanism to transfer the link in the first place, to determine who you're getting the file from, and then you might as well use that to transfer the file instead. Also people want to be able to do it asynchronously, so they use things like WeTransfer.
During the brief period that open Airdrop / bluetooth file transfer was a thing, there was a short fad of spamming porn to nearby people on public transport. So that was the end of that.
> During the brief period that open Airdrop / bluetooth file transfer was a thing, there was a short fad of spamming porn to nearby people on public transport. So that was the end of that.
Seems like such a simple fix though... Blur the shared photos unless you tap preview. Or unless it's coming from someone you have in your contacts. Or just not have it show the preview at all and obviously you would decline files from someone you aren't expecting to receive files from.
Or the simple fix of just not having this P2P transfer option always enabled. It should be off until you toggle it on because you and someone you are with want to transfer a file.
I believe that's what Apple did for AirDrop, "Everyone for 10 Minutes" is available in AirDrop settings. You can also use NFC (Near-field communication) to initiate a transfer with a non-Contact, while optionally establishing a Contact relationship. If only this were also available on Android.
I think it'd be great if Apple supported this, even if it meant an Apple AirDrop app for Android. Especially if it meant an Apple AirDrop app for Android.
AirDrop was a huge asset to protestors in Taiwan. It was heavily used for mass demonstrations. Something that works cross-platform could be really great for political movements
Modern American SUVs are an abomination too. The American auto industry started pushing them because they're legally classified as "light trucks" which lets them take advantage of certain safety and environmental standard loopholes
Yes, but it's no harder to get your groceries with an SUV than with a compact car. The firehose metaphor doesn't make sense; you're not going to accidentally wash all of the data off of the recipient's computer if you're not especially skilled in handling bittorrent.
The problem with bittorrent is ports, just like ipfs. I have to tell somebody to open a port to the outside who may never use bittorrent again.
Opening ports can be obnoxiously hard for someone who doesn't know anything, even if it sometimes just means finding the UPnP checkbox; 90% of the time it involves trying to figure out how to access the UI for their router, and after that trying to figure out what their password could possibly be or how to reset it.
Now, they've got a port sitting open for a piece of software they might never use again, and that's not something I want to be responsible for.
People who often share files should be setting up standing private networks. Group chats/texts can last for years, they should be packaged with an entire range of services that the members can easily provide for themselves (like file sharing and voice/video messaging.) So many companies make their money from centralizing and siloing this.
Very different use case. It seems both too heavy weight and not capable enough for e.g. sharing a screenshot or PDF from an Android phone to a Linux laptop without Internet connectivity.
The same reason universal healthcare and free education is not widely adopted in the US. BitTorrent is quite “widely adopted” in other parts of the world.
Recently I had to send file from Whatsapp to Telegram, because apparently it is forbidden to download file from the Whatsapp and it's a "feature". Facepalm....
PS: afaik IPFS doesn't guarantee file storage, a separate paid middleman is required for that.
In my version, the entrypoint is not uploading your file (where would it go??) but establishing the connection between two devices, then bidirectional transfers between them.
Most other solutions don't allow pairing of devices across networks.
TFA's "file.pizza" only allows to initiate a session on the device that uploads a file, which makes it tricky to share a file from a mobile device to a laptop (due to tricky QR code scanning with the laptop camera).
PairDrop allows cross network pairing (mobile device can scan QR code from laptop screen), and file uploading from both sides afterwards.
Heh, seeing PairDrop motivated me to make sth similar, but more as a toy/exercise in messing with idiosyncratic/home cooked software:
https://sonnet.io/posts/reactive-hole/
And https://github.com/psanford/wormhole-william which is a Go reimplementation of the client. I only want to point this out specifically because an apt-install of magic-wormhole on Ubuntu 24.04 actually results in a program that does not work (the beauty of python dependencies at play?)
Other readers, please do note that (the unfortunately named) wormhole.app is unrelated to the frequently recommended, heavily peer-reviewed and much longer-standing magic-wormhole.
If having someone intall transmission (or your favorite torrent client) is not a hurdle, I like the privtracker approach a lot :
https://privtracker.com/
The reason I like it more is that most torrent clients can run in the background by default so it's not dependant on keeping a browser tab opened
It made it to the frontpage not so long ago but it'd be a pity if you had missed it
Ignorant question: isn't WebRTC just... built into the browser? Do you really need a stack of 20 things to tell the browser to connect to another browser with WebRTC? Isn't one HTML page with a few lines of javascript enough?
This is actually a good question for you. You have a multiplayer browser game and you want to swap out the websocket you’re using for webrtc. What all would that change involve?
That is correct and s3 are in 3 different regions with object lifetime of maximum 10 days, it is backed by s3, the idea is to have the simplest code for anyone to review what it does (encrypt in browser and send encrypted blob to s3, key never leave browser)
I sit behind a keyboard, mouse, monitor, and an incredibly powerful desktop operating system for 99% of the working day. These devices are pretty much the pinnacle of human-computer interaction; arguably the best tools we have for interacting with digital content with speed and efficiency.
But as soon as I want to do something involving my phone, I have to physically reach for it and immediately hamper myself with its limited UI, screen size, and ludicrously locked-down ecosystem limitations.
Smartphones have been around for decades and yet we're still nowhere close to seamless integration with the rest of our devices. The best we've got are clunky half-featured workarounds (Airdroid) or overly-complex techy solutions inaccessible to laypeople (VNC).
As another commenter said, it's all very much intentional. It's a deliberate choice on behalf of greedy phone manufacturers and greedy app developers. And it's really, really frustrating.
Link to Phone sends all your data (Messages, calls, notifications) to Microsoft. It also requires a Microsoft account. Admittedly for file transfers it's a bit different, if you're on the same network it will attempt a direct connection so MS won't get your files. It still sends the meta data (file names, file sizes) to Microsoft, though.
Similar issues with Smart Connect from Motorola.
An entirely local solution like KDE Connect is better, if your situation permits it. Unfortunately it has been quite unreliable for me (and I have tried many devices) but it seems to work just fine for others!
Imagine being able to just send a file from an Android phone to an iPhone without a centralized service and an Internet connection (i.e. like we could in the time of feature phones and early smartphones via Bluetooth)...
Please think of the shareholders and the lawful interceptors before you suggest something as subversive!
Where do you get the FTP client and server from without an Internet connection, and how do you create a network between the two?
And would you say that this is comparable in terms of complexity with e.g. Airdrop or selecting "send via Bluetooth" and picking the recipient's device name?
> Where do you get the FTP client and server from without an Internet connection
Until last year, your web browser will usually download files. These days, you have to start an HTTP server. Which is actually easier, because FTP is a messy protocol.
> how do you create a network between the two
WiFi Direct has been built into phones for at least a decade.
> And would you say that this is comparable in terms of complexity with e.g. Airdrop or selecting "send via Bluetooth" and picking the recipient's device name?
On the sender side, the "send via" option can appear in the standard sharing app list. On the recipient's side, you may need to scan a QR code to finish the WiFi Direct connection. Starting the download should be as easy as having the sending app pretend to be a WiFi login portal so the phone automatically pops up the web page.
But if you're just sending files offline, there's always Nearby Share or plain old Bluetooth if the files are small enough.
> On the sender side, the "send via" option can appear in the standard sharing app list.
Can, but does it? Defaults matter. And how would the receiver be notified that they should download some file via FTP?
As long as such a feature does not come preinstalled on smartphones, I'll continue considering this lack of previously commonplace functionality an intentional vendor lock-in.
>how would the receiver be notified that they should download some file via FTP
You tell them "hey I want to share a file with you, scan this QR code". The QR code sets up the WiFi Direct connection, the fake portal login should auto-open a "click here to download" button (or redirect to a file, but I don't think that's allowed), and once the file is downloaded you terminate the Wi-Fi Direct connection.
But that presumes phones don't have a method to share files. They have that feature built in. It's called Nearby Share on Android and AirDrop on iOS. Both use some weird pairing mechanism and some form of Wi-Fi Direct to transfer files, but the interface is just a bit more integrated.
When Apple opens up Airdrop or when Google convinces Apple to pre-install Nearby Share, we'll get the universal file transfer we desperately need.
What about people who have never heard the term "FTP" and don't know what a client or a server is?
Nobody cares what we do, we know how to use our computers well, and will force them to do what we want them to do in ingenious ways, and we will share those ways with each other. The problem comes when one of us puts that solution into a user-friendly mobile package that can be installed and run with your elbow, and then somebody makes a tiktok about it.
That app is getting nuked. Maybe even the internal API that enabled that app is getting nuked. If it's a standard protocol, it's getting extended and extinguished. The people who made it and the people who host it are getting legal letters.
The fact that Google and Apple could quickly agree on a standard for both cross-platform Covid contact tracing and "stalker warnings" for "Find My" trackers, but not for cross-platform encrypted text messaging or an interoperable AirDrop extension, shows that it's purely a problem of incentives.
> no first class standardized ways to move files over the Internet between PC/mobile/edge devices
FTP? You can open an app on your phone, start an FTP server, use UPnP to poke a hole in the router, show their public IP address, send a text message to your friend with the IP, port, username & password in a single URL, connect, send/receive files.
I meant modern -- you can use FTP over stuff like ZeroTier or Tailscale but otherwise you can't do P2P with it (firewalls, V4 NAT) and it's not secure. TS has some facility for transfer but again-- TS-specific, not available everywhere, not standard, and not suitable for all cases.
I also meant things regular people can easily use and that can be used as conveniently as e.g. Apple's AirDrop (which is nice but only works between Apple stuff).
It's part a UI/UX problem and part a missing standards problem. The latter precedes the former.
> firewalls, V4 NAT
That's why they added 'use UPnP to poke a hole in the router'. Which will work on most networks, though CGNAT will still break it if IPv6 isn't available.
There are plenty of other tools out there that can send files between devices. Google+Samsung's Nearby Share work pretty much everywhere. KDE Connect works on any device I can think of. I wish Google+Samsung would make it an open standard but I'm guessing they won't do it so they can rewrite the app whenever they please.
The biggest, and IMO only, problem for AirDrop competitors is that they're not pre-installed on iPhones and iPads while AirDrop is. AirDrop is nothing special in itself, though Apple did implement it in a rather weird way. All you need to mimic it is Bluetooth (BLE if you're fancy) for handshakes and WiFi Direct for transfers.
This is the same predictable reply as the naysayers at the launch of DropBox. Both of us know that expecting people to set up FTP is a complete nonstarter.
Has anyone used this kind of technology to create a kind of one-on-one messaging system that maintains a persistent thread (in browser storage) which can sort of simulate "texting" but without the phone?
Very nice. It reminds me of a similar all-in-browser file transfer tool I built ages ago called nearshare. This was WAY before webrtc was a thing so my approach was to actually run a web server in the browser via a java applet. :)
I've also never been able to get these P2P web file transfer tools (FilePizza, ShareDrop) to work without issues. Transfers inevitably fail partway through, especially for large files. This seems to happen even in ideal network conditions such as over a LAN.
I am intrigued by this. I read everything on your site. It looks great since it apparently allows transfer between devices using different OSes and that is always the sticking point around my place. I have several incarnations of Windows (7-11), a couple of linux distros (PopOS, CentOS7), and iOS on our phones. I see that linux is currently not supported though you would add that if people request it.
That's great.
My question for you is about the security of the data being transferred. You're using TLS according to your docs and this app transfers directly peer to peer. Is this secure FTP using TLS?
You have two tiers for users - Community and Business. Community is free and donations encouraged. Speeds may be slower to prioritize paying customers and support is more crowd-sourced. Business gets fastest speeds and direct support.
I am not a subscription buyer by choice. I would like to help make this profitable for you. Would you consider offering a paid version for personal use that would give faster speeds, security updates, and bug fixes at a price point between Free and Business? $300/year is way too much for something that would be used as a personal tool to quickly and securely send documents and photos to family members.
I realize that the donation model could function like a one-time payment model since you are likely using it intermittently and sending a small donation for each use so that your annual costs are minimized. In that case you always use the most current version. You "own" that version during the period that you use it and you pay a reasonable donation for use of it.
I also don't see the need to establish an account if this is a p2p service since the data transfers should walk from my device to the destination device. Fill me in on why I need an account.
I would pay for a license to use this with the expectation that the license would provide the current version of the app plus all bug fixes and security fixes for that paid version and that upgrades taking the app to the next full version would be discounted to existing users. I could be a long-term customer.
As an example, I use an antique, unsupported version of SnagIt on my machines. I purchased the license years ago, upgraded through a couple of versions until they got to a point where they dicked up the interface and changed the tool availability and so I ditched the newer version and have continued using the old version which work great. I still get the nag screens to update to the new version but the click to close that dialog is now muscle memory for me.
I appreciate the functionality that this app, blip, provides and would like to be a paying customer and use the app but I'm not interested in a subscription model.
EDIT: I forgot to note a slight error in one of your replies to a FAQ.
Under the "Blip vs Aspera" comparison in the FAQ "Why is Blip easy to use?" there is a fat-finger spelling error.
Hey, really appreciate such thoughtful reply. I’ll address your questions while explaining our design decisions and how Blip works.
We set Blip to use email addresses because we wanted to make it convenient for people who are less tech savvy and for business customers who need to quickly find and know who they’re sending files to. If you sign in on another device, all your other devices and recent people are just a click away—so you don’t need to set up or sync that list by yourself.
Blip is a local-first app in the sense that it works with files on your devices, but the interactions are server-driven, letting you negotiate transfers with your devices and other people, no matter where they are. When transferring files, we try to connect devices directly over IP, but when that’s not possible (and it often is not) we relay files over our servers. We use TLS 1.3 to encrypt files in transit. When devices are connected directly, we use mTLS for an even higher level of security. We plan on adding full E2EE in the future.
We care a lot about speed! We don’t throttle transfer speeds when devices are connected directly. Sending files on home Wi-Fi should be as fast as possible, as long as devices can ping each other. Reduced speeds only apply when using our relay network. If demand is high, business customers get priority to ensure their work is delivered on time.
Our business model is still very much evolving. Our main goal was to structure it in a way where people who benefit from Blip commercially should be supporting it the most. We considered a licensing model, but Blip relies on infrastructure maintenance and continuous development, so we need everyone on the latest and most secure version. We decided to make a clear distinction between community and business users, because we learned there’s more demand for speed at work. Of course, if community users start experiencing slow speeds (in practice, this hasn’t been the case), we’d love too bring this to personal users to. One way is for one-time donations to provide high-speed data boosts. Since personal users don’t require extra support and business features, pricing can be more affordable.
All that said, it’s so good to know that speed matters! Our goal has always been to make Blip the fastest way to send files.
Thanks again for the feedback, and for the heads-up on the typo—already fixed! :)
I suspect that I will give this a try on some of my devices. Thanks for the informative reply. I noticed that your Windows support begins with Win10. Does that mean that it won't work at all for Win7 or that it might not work?
I have a couple of Win7 workstations that could use something like this.
Nice project and I always like playing with WebRTC but there is something that has me a little concerned .
> Transfers are now directly from the uploader to the downloader's browser (WebRTC without WebTorrent) with faster handshakes.
Maybe I'm wrong, but there is a signaling server in the middle somewhere along the chain here no ? unless it's just the same as PeerJS in which you first need the clients ID, but connection can be flaky.
From the source I can see it's using PeerJS but react is throwing me off a little bit. It's not clear to me what `useContext(WebRTCContext)` is..
Is it strange that non of these ever worked for me over the years in different places/setups? (between windows/linux/osx). Literally never. Always been thinking of writing my own… I guess thats why there are so many :p
There must be dozens of services like this (ie. peer to peer file sharing over webrtc), but I can never get them to work. Presumably it's because often times one or both of my devices are behind strict NAT, and the service doesn't provide a TURN server (understandable, given that it might be bandwidth intensive). Does anyone know any public/self-hosted service that provides a TURN server?
We tried something similar 17 years ago. We couldn’t achieve true P2P, but we managed to relay a data stream via a server without store-and-forward. The startup was called Pipebytes, and we even got a bit of news coverage: https://www.youtube.com/watch?v=ATqKvra1X3o
It was later sold to another company, which scrapped the P2P part and repurposed it for regular cloud sharing. :(
Why can't we have a mixed system? A Dropbox like service with built-in file sharing. If there are no other peers or the speed of transferring from peers is slow, you use some servers for seeding.
Cool concept, has been done a few times before. Would prefer to see a cleaner implementation. Do projects like this really need Tailwind, TS, React? I don't think so.
This particular project has existed for a decade. Any file transfer service which survives that long is worthy of praise, especially now when open-source solutions are being gobbled by LimeWire.
In my time we just wrote very small on scraps of paper or tore pictures from magazines. We folded them tight into a compact rectangle, then we folded that rectangle across a rubber band between our thumb and index finger and with the other hand we stretched that rubber band enough so that when released, it would propel the folded rectangle of paper across the intervening distance rapidly enough that the adversarial player in the room could not detect the source or recipient of the rectangle without querying the entire congregation.
This method eliminated potentially adversarial middlemen in transit who might, if you chose to pass it through multiple players (servers if you will) - read it in transit though the message was not intended for them, and then use the contents against you later.
It had the disadvantage that one needed to insure that the sender and recipient were in sync in case the aim was off and the message bounced to an unintended recipient.
I once had the misfortune of sending a tightly folded, secure message that was part of a war game being played during English class, and having that poorly aimed message hit the largest mass of muscle in the class right squarely in the ear because the recipient was busy gloating over the success of their previous move and wasn't able to secure the reply in transit.
We all heard the light snapping sound of the rubber band followed by an uncharacteristically loud profanity from the unintended recipient, my own barely stifled gasp of horror, lots of giggles and laughter from the audience, and as they turned - the beginning of the next round of the Inquisition by the adversarial instructor who mistakenly thought we were all watching the English lesson on the board in real time instead of conducting paper war games in the background.
"It's peer-to-peer, trust me bro!" The problem is that you are still using a website provided by a third-party to serve you the JavaScript program that initiates the transfer. It's easy to replace that JavaScript by something that just transfers a copy to the third-party itself. To be sure that the transfer is actually peer-to-peer, either the sender or receiver should run their own fillepizza server (and have verified that the source code does not contain any backdoors or phone-home code). But if you do that, you actually don't need a peer-to-peer solution anymore, it's turned into a client-server problem.
hmm, it says "Drop a file", not "Upload", on this step it uploads the file to your local browser for sharing, but the file is not actually uploaded anywhere on the outside
Also, un-fun fact and coincidence... Peter Bright, formerly of Ars Technica and arrested for Child Enticement, had the nickname of "Dr. Pizza" on the Ars forums.
I keep a long list of browser based and CLI p2p file transfer tools[1].
LimeWire (which now has its crypto currency probably) has been on a rampage recently aquiring some of really good tools including ShareDrop and SnapDrop. https://pairdrop.net/ is the last one standing so far.
[1]: https://gist.github.com/SMUsamaShah/fd6e275e44009b72f64d0570...
Probably you can also add Dragit[1], which is a desktop p2p file sharing tool for local network with automatic host discovery. Currently supporting Linux and Windows. (author & maintainer here) I'm not sure if I should keep on working on the tool, considering the length of the list so far. :D
[1]: https://github.com/sireliah/dragit
https://wormhole.app/ has been spared and is pretty good. Encrypted, dl can start before up is finished, decent size limit.
Unrelated to the wormhole python cli tool and associated file sharing protocol.
Both not to be confused with Web Wormhole, which is also pretty good: https://webwormhole.io/
Slightly different approach – "P2P first", i.e. both sender and receiver need to be online simultaneously throughout the transfer, but there's a TURN relay, so it should work in almost all network constellations.
I use https://onionshare.org/. It's not p2p afaik, but dang! that one is easy to work with.
It's not a p2p tool btw.
It can be, if you send files larger than 5GB. https://wormhole.app/faq
Yeah, it uses webtorrent behind the scenes: https://webtorrent.io
...which is freaking awesome torrent software, by the way.
It's okay - 99% of the video files I download have to be opened in VLC, though :/
But still, being able to almost immediately stream, even if through VLC, is pretty nice.
You should add sendme, it's one of the best I've tried for the CLI. https://www.iroh.computer/sendme
The Galene videoconferencing system <https://galene.org> includes peer-to-peer file transfer. The web client is built in, but there's also a command-line client at <https://github.com/jech/galene-file-transfer>.
My previous company used WeTransfer a lot, because we needed to send large filesystem images and Android releases to and from China, and the great firewall hobbles obvious things like using gdrive.
I use https://justbeamit.com
Was very annoyed when they acquired ShareDrop.
/? inurl:awesome p2p site:github.com: https://google.com/search?q=inurl:awesome+p2p+site:github.co...
Peer-to-peer: https://en.wikipedia.org/wiki/Peer-to-peer
I noticed this when i was actually looking for something exactly like this tool earlier in the week. I didn't realize it was a recent thing.
In the CLI section, magic-wormhole is missing, instead you have wormhole-williams which is just an outdated implementation in GO of the original
Not sure if it's p2p, but I also find that this exist: http://xkcd949.com
Over http?
Bless you.
Opera browser used to have P2P file transfers as a short lived feature in ~2010, called Unite. I remember it also had skeuomorphic GUI of a 'fridge' where users could put post-it style notes that could be seen by others.
One of many everything-and-the-kitchen-sink features Opera Presto had during its heyday. Others included a separate Bittorrent client, desktop widgets that could be moved outside of the browser window, full IRC client, email client and peerless hotkey actions customization.
By some miracle the browser still managed to be a rather lean binary.
Can we have that do-it-all Opera back? RSS, email, torrents.
Feels like we had it all internet wise in 2007-2010 and then decided to throw it all away.
We did not decide it. Google decided to kill it. In countries where Opera had major share Google ran aggressive and deceptive (something something faster) campaign with billboards, radio and tv ads. Chrome ads were also everywhere on their homepages (google.com, youtube.com). But more nefariously, Google kept blocking features and apps based on the UA agent alone. Add lots of tech demos with their custom extensions.
Don't forget bundling Chrome with random apps (I remember cCleaner), making it install silently and automatically set itself as default.
I got caught by this as a kid a few times, I was technical enough to know what was going on, and reliant on a screen reader (which Chrome didn't support back then), so it was definitely a memorable annoyance for me, but I guess quite a few people didn't care.
They did that in pretty much every (developed) country not just those where opera has major share.
Good point, I missed a word or two there to make it clear I didn't mean it was only there.
Do you mean Opera Unite, that had p2p file sharing and a 'wall' (I think it was termed the fridge door, all your verified users could leave you notes/images on it IIRC).
I blogged about it back in the day (15 years ago), https://alicious.com/opera-about-to-change-the-world/.
I think Vivaldi have both RSS and email, it's sort of the spiritual successor to the original Opera.... I miss the old Opera.
Vivaldi is roughly 1000 times slower. You need a pretty good computer to run that UI. It also lacks extremely basic features Opera had; like working LRU tab switching. I liked the idea, but it's impossible to recommend.
Is that true? I remember having to change a setting to switch the behavior of tab switching because it was LRU by default and I prefer it in visible order.
It used to work and broke maybe 2 years ago. This tells me that no one is actually using the browser and that no one is really working on it either. It receives chromium updates and then some money-making features here and there.
have you tried Otter Browser?
What a blast from the past. 0 comments, 0 points. Opera wasn't very popular in US. https://news.ycombinator.com/item?id=7937436
It's been a while, 8-10 years ago maybe? But quick look now tells me it's still one person effort. That's both awesome and unfortunate. I wish it got more traction back then to attract more active user/dev base.
> One of many everything-and-the-kitchen-sink features Opera Presto had during its heyday.
oh the Presto engine.. shame its not the same opera we used anymore. still has the best ux on phone, unfortunately no other browser come close.
I remember M2, their mail client, which had good "AI" auto labelling of e-mails. For today's standards probably not outstanding, but back then it worked nicely, and I wish I had something like it for Thunderbird, but so far any plugin to auto label anything in Thunderbird has failed me. Thunderbird needs tagging to improve and be better accessible.
I really wished opera had a greater market share than it did. It did relatively well for a few years with share between 1-4%. But was lagging behind defunct browsers like IE6. And back then the browser space was only chrome, Firefox, and IE. Notable mention to safari and KDE fwiw.
The everything browser made it a difficult experience to understand. Kind of a feature overload in the face of minimalism being practiced by chrome and ie7.
I remember this fondly. How much more beautiful the web could have been if google had not killed everything else.
Someone made a torrent website software for it which spawned something like 50 good torrent websites. Combined with the build in torrent client and irc client it made a wonderfull experience.
Opera has an operator mode now btw. I think it slipped through the hn radar. Maybe 2 weeks ago was the announcement? Hit producthunt's main page
I still need mouse gestures in all browsers and extensions are still in comparison hot garbage at it.
Ah yes, back when browsers were actually user agents.
The thing that usually annoys me about these services is they tend to give you an intractably complex URL to share with the recipient. This poses a problem because every time I need such a P2P transfer, I’m communicating with someone over the phone and they need the file on a computer (which may not even be their own, so email is also cumbersome).
https://file.pizza does this better than most, as the URL consists of real words. But all the words are ingredients in English which comes back to being an issue again.
https://pairdrop.net is my go-to, since it allows creating temporary “rooms” with just five letters, which are easy to share over the phone.
Still, I continue to wait for the holy grail of a P2P service which would allow me to initiate a connection via CLI and get a simple URL to share with someone who could download the file from a web browser, saving me from having to babysit the browser tab. There are services which allow you to upload via CLI and download via web browser, but they host your file so you have to wait for the full upload to finish before sharing the link.
One tricky constraint is that a "simple URL" isn't big enough to hold a full-entropy encryption key. So your security must either come from PAKE (like magic-wormhole and friends), or from the good behavior of some intermediary. And PAKE requires a peer who knows the plaintext and will only execute the protocol once, which means it really needs to be the person you're connecting with and not an intermediate webserver.
I think it's a 2-out-of-3 trilemma: end-to-end encryption, short codes/URLs, offline/non-interactive workflow: choose two. Or framed differently, if you require proper encryption, then either the code/URL must be long enough to hold the full key, or you must use an interactive (PAKE) protocol which means both agents must be running at the same time (babysitting).
Your last point is an interesting one: we could build a form of magic-wormhole where the sender's CLI waits, the recipient gets a URL, the URL points to a web page which performs the client side of the protocol. The server wouldn't host the file, just the decryption agent. Basically wormhole receive in a browser. That would match many of your goals.
However I'd be hesitant to do this with magic-wormhole because it opens up a vulnerability we don't currently have: the web server hosting that page could silently swap out the JS with a version that retained a copy of the plaintext, perhaps only when the browser is coming from a specific IP. You can't audit a webserver for consistent+correct behavior the way you could with e.g. the contents of a Debian distribution.
That said, the usability gains of the recipient not needing a CLI tool installed might be worth the tradeoff for some folks.
(I'm the author of magic-wormhole)
> a "simple URL" isn't big enough to hold a full-entropy encryption key.
I don’t care about that most of the time. When I do I’m unlikely to trust some random web service anyway (how do I know the author didn’t turn rogue the day before and decided to send a copy of every file to their own server?).
The service could offer a choice, where picking the short link comes with a big red warning. That could even be hidden under some setting on the page, since it’s the sender who needs to understand the implications.
> the usability gains of the recipient not needing a CLI tool installed might be worth the tradeoff for some folks.
That’s exactly what I’m looking for. Whenever I need one of these services, there is 0% chance the person on the other side would know how (or have the patience) to install a command-line tool.
> I'm the author of magic-wormhole
Thank you for taking the time to expand so thoroughly from experience.
Just use a link shortener?
The goal is to reduce complexity, not tack on more crap on top. The solution I have now with PairDrop is already more convenient than that.
> One tricky constraint is that a "simple URL" isn't big enough to hold a full-entropy encryption key.
If you trust the server not to MITM you, then you don't need the encryption key in the URL. The URL only needs to be long enough so it cannot be guessed by an attacker, 64 bits should be plenty. Once the peers connect to the common URL, they can generate an arbitrarily large key by performing ECDH through the server. (This is where you assume that the server is not doing MITM.)
I wonder if you can use something simple like numbers to get it started, then use something in the poster's phone conversation can authenticate it.
Basically type in encoded/crc'd ip address then some code over phone to start session
(none of this requiring someone else's servers/etc)
> the holy grail of a P2P service which would allow me to initiate a connection via CLI and get a simple URL to share with someone who could download the file from a web browser
Now tell the receiver to connect to <https://galene.org:8443/group/public/somethingdifficulttogue...> and login as john with an empty password.> There are services which allow you to upload via CLI and download via web browser, but they host your file so you have to wait for the full upload to finish before sharing the link.
There are exceptions to this; I've been making copyparty[1], an httpd which lets you start downloading a file that is still being uploaded[2]. If you catch up with the uploader, it'll throttle the speed so the browser doesn't drop the connection. Uploads and downloads can be done through browser and/or cli.
I recall there was at least one other alternative with similar functionality somewhere on the awesome-selfhosted list, but I'm failing to find them right now... It was prominently mentioned in the project's readme, but maybe that's no longer the case.
[1] https://github.com/9001/copyparty
[2] https://a.ocv.me/pub/g/nerd-stuff/cpp/2024-0418-race-the-bea...
> copyparty
Great name!
Unfortunately this seems like it’s something I’d need to host myself, and that’s something I specifically don’t want to do. I only need to share on occasion, and always want to do it with the least hassle possible.
Yep, and the server bandwidth can become a bottleneck if the peers are fast enough, so true peer-to-peer is still the better choice, or something webtorrent-based if multiple people are grabbing the same file.
But there's been enough last-minute submissions of DJ material by now that I'm still happy it was added as an option :-)
Why throttle the browser rather than just having it block until more data arrives?
https://rdrop.link gives you six characters. It's IMHO "telephoneable".
That’s a lot of red! I didn’t know about this one, thank you for the share. I suspect I still won’t use it over PairDrop because the web page is too busy, the “Check out my other projects” completely draws the eyes, and I want something that’s clean and not distracting for the receiving end.
You seem pretty determined to not have your problem solved.
> initiate a connection via CLI and get a simple URL to share
https://webwormhole.io does this, see the CLI link at the bottom. Just tested it myself with a small file.
This does look quite close to what I wanted. Thank you. Unfortunately, it also looks to no longer be under development.
It says that the last commit is from 2 years ago. Is it because it is completed, or because it really is no longer under development?
i'm the author. i keep a close eye on it for any security issues but i'm not adding any new features, hence the lack of commits.
i also obviously maintain the instance on https://webwormhole.io/.
Thanks for maintaining it! You might want to update the CLI instructions to use "go install" as the current command doesn't work.
It wasn’t the lack of commits which made me think this was abandoned, but everything else (outdated instructions, issues and pull requests open with no reply, giant warning at the top of the README…).
https://news.ycombinator.com/item?id=43351944
Yeah, the installation instructions should probably be updated at the very least, and perhaps that warning should be adjusted as well.
That is what I thought. Thank you for clarifying.
If it were completed, the author should have closed/rejected every issue and pull request and removed this large warning at the top of the README:
> THIS PROJECT IS STILL IN EARLY DEVELOPMENT IT USES EXPERIMENTAL CRYPTOGRAPHIC LIBRARIES AND IT HAS NOT HAD ANY KIND OF SECURITY OR CRYPTOGRAPHY REVIEW THIS SOFTWARE MIGHT BE BROKEN AND UNSAFE
Plus, install instructions are outdated. As soon as I tried them, `go` complained of using a deprecated method.
So everything points to it no longer being under development.
Not much development can be done about experimental cryptography, you just use it and that's all. Cryptographic review can't be written either. Also you said you don't want much cryptography.
> Not much development can be done about experimental cryptography
That’s not the bit that matters, it’s the “this project is still in early development” and “this software might be broken”. Those are the things which hint at the project not being done.
Send a pull request and I will review it personally. :P
What about creating and seeding a torrent with a CLI then creating a shortlink to magnet link?
That is the opposite of what I want, everything about it is harder to share over the phone. Magnet links are not exactly short and now I’m asking people to install a BitTorrent app too, on a computer which might not even be theirs.
The file.pizza one doesn't look like it's peer-to-peer. You upload a file to their server, and then they provide a download URL you can share. Kind of the opposite of peer-to-peer. I would expect a "P2P" file transfer product to not require any intermediate storage besides the sharing user's and the recipients'.
It is peer-to-peer, via WebRTC. It says right there on the homepage, when you start a connection, and on the FAQ.
Oh, nice! Totally missed that.
I wish there was a way to do local peer discovery with WebRTC. Right now both endpoints need an active Internet connection and a shared identifier (in this case a special URL) in order to find each other. Can't do offline local sharing.
You can! https://github.com/pion/offline-browser-communication
It uses mDNS for discovery. You can only do one browser though.
I don’t see a path forward on browser/browser that is obvious. It would make it so easy to fingerprint if you could set your mDNS hostname in JS
If one end of the connection is a native app like this you have plenty of other options. Browser to browser is the use case I'm talking about.
It could be done with a browser-owned dialog to select peers instead of exposing all local peers to the web by default. Similar to the web MIDI API or others that expose local devices only with explicit user permission for the specific device.
A QR code should work if at least one of the browsers has camera access, I suppose?
https://github.com/n0-computer/sendme
iroh's stuff is great but their local peer discovery can't work in a browser, since it uses an mdns-like protocol to do it
I solved this issue by implementing a webtorrent tracker[1] client. Signalling server is still needed, but with this approach any webtorrent tracker can act as one.
[1]: https://github.com/webtorrent/bittorrent-tracker
Sharing identifier maybe we could do with qrcode, chirp audio protocol, nfc tap. Ios has peerconnectivity that works really as p2p network but sadly no web api and doesn't work android (not sure someone reverse engineered protocol)
Somebody indeed has, but since it uses a custom low-level 802.11 variant, I don't think it's feasible on (at least non-rooted) Android devices: https://github.com/seemoo-lab/opendrop
Couldn't you use sound/bluetooth/qrcodes/etc. to do signalling?
I once did it by copying messages from textarea's back and forth.
> Because data is never stored in an intermediary server, the transfer is fast, private, and secure.
But WebRTC needs a TURN server for when hole punching/STUN doesn't work when both clients are behind NAT.
Data is never stored in an intermediate server, but it can pass through.
How is the privacy and security ensured that the TURN server won't/can't read your data? Do you just have to trust them? Or is a form of E2EE employed?
I'm surprised this isn't even metioned on the page. Or does this not include TURN servers, and so file transfers just fail between certain peers? (Which it doesn't mention either.)
WebRTC, in fact, merely passes e2e encrypted packets through the TURN server (which, by the way, is only required if both sides are behind symmetric NAT: the vast majority of NAT doesn't cause this problem, though you might need to do STUN).
> the vast majority of NAT doesn't cause this problem
Hard disagree, I've yet to meet anyone in my country that has gotten any WebRTC service to work at all.
FWIW, this doesn't actually imply we disagree, as maybe the vast majority of NATs aren't in your country ;P... we could both be right!
A lot of cell networks won't work with STUN. I've tried in personal projects to have a home computer with wifi communicate through a stun server to a mobile device using mobile data. It don't work.
> the vast majority of NAT doesn't cause this problem
A WebRTC clients behind an iptables based MASQUERADE NAT will not work without TURN. Which both incredibly common and weird that people designing WebRTC and STUN/TURN/ICE never stopped by netfilter developers to make iptables work out of box with WebRTC.
TURN or STUN server can use the DTLS transport in order to encrypt the traffic.
So you know it's secure if you are using turns:// protocol and verified the certificate just like it works with https://
https://datatracker.ietf.org/doc/html/rfc7350
Hmm. I'm not a WebRTC pro but looked into it recently for a hobby project and felt that the typical WebRTC TURN implementation still leaves the TURN server in a quite trusted position. My rough understanding:
- (1) Each client generates a key pair
- (2) The fingerprint of the public key is part of the SDP message each client generates
- (3) The SDP message is somehow exchanged between the clients, out of band, and the session is started. The client's verify the remote peer using the public key from the SDP message.
The problem is that it's not really feasible in most circumstances to exchange the full SDP message out of band, so instead the service provide some mechanism to map a shorter ID (typically in a URL) to a centrally stored copy of the SDP. I think this might be where it happens for filepizza [0].
This means that a malicious file sharing operator, being in control of both the TURN service and the out-of-band signalling mechanism, could just MITM the DTLS connection and snoop on all the data going by. The peer's think they have each others public keys but they just have two keys owned by the server.
[0]: https://github.com/kern/filepizza/blob/main/src/channel.ts
Only the initial SDP needs to be fudged. The attacker could just set up two clients that pretends to be the sender/recipient. Then the data can just go through regular Google TURN servers.
In WebRTC, TURN server is only used to establish a data channel. After that, data transfer us peer-to-peer.
https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/...
That's incorrect. What you're describing is STUN, when it works. TURN is what is used when peer-to-peer remains impossible. All data transfer is via the TURN server.
OP can just not use a TURN server, and it won't work for double-NAT traversal. I did this in a side project to avoid the security risk.
But you can punch holes even when both clients are behind NAT.
How so? With both users behind symmetrical NAT? TURN does not count as punching holes IMO.
Both clients send a packet to a server, server sends the remote IP to both parties, both parties try to send traffic to either’s remote IP. Unless their nat firewall is evil, this should work.
That doesn't work with "symmetric" NAT, which was specified by the person you are responding to: in that case, you can't rely on even a third party to figure out the port. To the extent to which this NAT paradigm is chosen for its efficient usage of ports, this is fixable using UPnP/NAT-PMP/PCP, but 1) I've (sadly) never seen a WebRTC implementation which takes advantage of these protocols, and 2) usually this isn't chosen for it's port efficiency: it is chosen because the NAT provider is incompetent (or even actively "evil", lol), and so they are almost certainly also not going to support a port mapping mechanism.
Regardless, I'll claim that the real disagreement is more over how common symmetric NAT is: I claim it is very rare, and that the vast majority of NAT isn't symmetric... however, in another thread, the user you are responding to claims that "in [their] country" they've never seen WebRTC work at all. I'd wager that's a pretty local issue, with what probably amounts to a local oligopoly built with similar limitations, but if you live in that world it must be brutal. However, that's not WebRTC's problem: we should implement port mapping in clients and ISPs should, to put it as kindly as feels fair, "fix their shit".
CGNAT is increasingly common for large ISPs as IPv4 gets expensive.
There are entire regions of brazil where all residential internet is CGNAT'ed, making any video calls between those users symmetric NAT.
What part of CGNAT requires the network address translation to be symmetrical?
> A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port.
My understanding is that it's not "required", but most of the CGNAT routers I've encountered do symmetric NAT, and they force-randomize the source port for each new connection, then keep it fixed for one external ip:port for some "session" duration, defeating traditional hole-punching.
When I've tried to build WebRTC P2P stuff I've experienced this making direct P2P WebRTC connections between CGNAT users nearly impossible, always requiring at least one node with a re-usable hole-punched public udp port or a relay server.
Such CGNAT should also be more likely to support PCP than a normal NAT. It does suck that, AFAIK, no browser has integrated support for this into their WebRTC stacks :/.
That's no longer p2p, that's using a relay server like TURN
It is p2p, the middle server isn’t relaying traffic.
If TURN is used, then it absolutely is. Please read the comments above.
Good point. I didn't think of that.
rather worried that it's going to go the same fate as ShareDrop (https://github.com/ShareDropio/sharedrop) and Snapdrop (https://github.com/SnapDrop/snapdrop) where they recently got taken over by LimeWire the crypto/AI company.
Wow, as someone who worked at the original limewire back until we got sued out of existence, this makes me sad to hear some scammers bought the IP and resuscitated the corpse of the company.
I wonder how much LimeWire pays to buy all of these foss projects, must be a decent amount if everyone is selling his solution
Wouldn't be surprised if the prices are fairly low actually, I would wager most of these projects make no income.
limewire aint touchin soulseek
and it has people building alt.clients
(though these are not webapps, which was your main shtick i'm sure)Yup. I recommended snapdrop to everyone in my family and friends for local data sharing without a cable.
When I discovered that it now uploads stuff to Limewire I was so annoyed that I had to admit I suggested a harmful tool for sharing private data. So much, that I will never recommend a similar website. Either I'll host it my self or suggest an installed tool through F-droid, if it exists.
I mean, it is entirely my fault. I knew the security risk, but set it aside, because I didn't think some known guy developing an open source tool would in his name try to grab your data.
It's so strange that this should have been a solved problem decades ago, but somehow a robust and secure non-commercial solution never gets off the ground.
Speaking of which, how is the IPFS project doing these days?
IPFS is in this weird state where it's getting barely enough updates and enough usage to not be considered vaporware.
It is partially being succeeded by Iroh.
https://www.iroh.computer/
Peer to peer sharing doesn't really have much opportunity for commercialization. The closest thing I can think of is bluetooth file sharing, which can still be a painful experience in some circumstances
Yes businesses tend to only work on interoperability when the interoperable product is just a complement to their main revenue generator. Like how Netflix releases clients for many platforms. No one is going to be motivated to make a (1) free (2) easy to use (3) cross platform file sharing solution. It'll also draw the ire of the copyright cartel. File locker websites have been harassed and "legitimate" cloud storage services are forced to police their user's files.
Not only sharing, bluetooth in general can be a painful experience in some circumstances.
It was solved a decade ago, BitTorrent protocol
I think people mean something seamless like AirDrop is on Apple devides, but some public standard that gets implemented on all platforms like iOS, Android, Windows, macOS and Linux, so all these platforms can just easily send files to each other simply and securely over WiFi.
> I think people mean something seamless like AirDrop is on Apple devides
Ha! I do wonder if I'm the only person who has errors where sometimes an AirDrop attempted transmission, from two devices sitting right next to each other, just hangs indefinitely, even if a transmission between the same two devices a minute ago succeeds. Like all Apple solutions that Just Work, it's great when it Just Works, but, when it doesn't, great effort seems to have been taken to make sure that there's no way to find out why not.
Torrents can be seamless. I take it you haven't used a download manager that would just grab any file, treating torrents just like any other download, as seamless as HTTP downloads are?
It doesn't have to be a dedicated system where you manage how long you seed, port forward, and other technical requirements: torrents already work well when you just seed while downloading because the server can never get overloaded, pretty much no matter how viral something goes. So long as it keeps serving the tiny torrent file, a few blocks on occasion, and the few packets needed to set up a NAT punch between people (STUN/TURN server? I always forget what's what), people can get the file from each other and you don't have huge bandwidth costs or have the site go down once the included bandwidth is exhausted. There's a reason Facebook and Twitter use(d?) this for distributing server updates¹, and I don't think someone remotes onto every server to visit the pirate bay, which torrent technology has sadly become synonymous to and people don't realise it is a transfer protocol just like FTP, HTTP, and other TPs that I'm forgetting
> some public standard that gets implemented on all platforms
What this is based on doesn't matter. It can be http, it can also be torrents. It's not very useful if you're sending files from and to one person almost every time (perhaps at the end of a holiday with friends, more than one person would want everyone's photos, but still), I'm just objecting to torrents being misunderstood as the only thing most people used it for: downloading copyrighted material in dedicated (and often unwieldy) software :)
¹ https://torrentfreak.com/facebook-uses-bittorrent-and-they-l... Article also mentions that a university cut 20 of the 22 update-distributing servers, I didn't know of that example
There’s no incentive for big players to play nicely with other platforms so they just won’t. Hardware standards like Qi2 are different since it affects costs directly. Software is usually built for lock-in since quite some time.
“Buy your mom an iPhone” and how Apple buried beeper mini into nonexistence was a nice example.
"Securely" is doing a lot of work here; you need some out of band mechanism to transfer the link in the first place, to determine who you're getting the file from, and then you might as well use that to transfer the file instead. Also people want to be able to do it asynchronously, so they use things like WeTransfer.
During the brief period that open Airdrop / bluetooth file transfer was a thing, there was a short fad of spamming porn to nearby people on public transport. So that was the end of that.
> During the brief period that open Airdrop / bluetooth file transfer was a thing, there was a short fad of spamming porn to nearby people on public transport. So that was the end of that.
My recollection is that the end of that was Apple's worry about the protests in China, not any concern about spam on public transit. (The first Google hit: https://restofworld.org/2022/apple-airdrop-china-memes/.)
Seems like such a simple fix though... Blur the shared photos unless you tap preview. Or unless it's coming from someone you have in your contacts. Or just not have it show the preview at all and obviously you would decline files from someone you aren't expecting to receive files from.
Or the simple fix of just not having this P2P transfer option always enabled. It should be off until you toggle it on because you and someone you are with want to transfer a file.
I believe that's what Apple did for AirDrop, "Everyone for 10 Minutes" is available in AirDrop settings. You can also use NFC (Near-field communication) to initiate a transfer with a non-Contact, while optionally establishing a Contact relationship. If only this were also available on Android.
I think it'd be great if Apple supported this, even if it meant an Apple AirDrop app for Android. Especially if it meant an Apple AirDrop app for Android.
I had a lot of fun airdropping rickroll videos to nearby phones while waiting for rides in disneyland
The DHT exists, all you need is an infohash and you get grab the metadata from peers/uploader.
libtorrent supports something called 'SSL' torrents that require both peers to be signed by the same root.
All the pieces are there to build on top of.
AirDrop was a huge asset to protestors in Taiwan. It was heavily used for mass demonstrations. Something that works cross-platform could be really great for political movements
Yeah, your can do your dishes with the fire hose too.
People drive one ton pickup trucks to commute to their desk job. Or to get two bags of groceries.
This is true but this sucks.
Modern American SUVs are an abomination too. The American auto industry started pushing them because they're legally classified as "light trucks" which lets them take advantage of certain safety and environmental standard loopholes
Yes, but it's no harder to get your groceries with an SUV than with a compact car. The firehose metaphor doesn't make sense; you're not going to accidentally wash all of the data off of the recipient's computer if you're not especially skilled in handling bittorrent.
The problem with bittorrent is ports, just like ipfs. I have to tell somebody to open a port to the outside who may never use bittorrent again.
Opening ports can be obnoxiously hard for someone who doesn't know anything, even if it sometimes just means finding the UPnP checkbox; 90% of the time it involves trying to figure out how to access the UI for their router, and after that trying to figure out what their password could possibly be or how to reset it.
Now, they've got a port sitting open for a piece of software they might never use again, and that's not something I want to be responsible for.
People who often share files should be setting up standing private networks. Group chats/texts can last for years, they should be packaged with an entire range of services that the members can easily provide for themselves (like file sharing and voice/video messaging.) So many companies make their money from centralizing and siloing this.
Yes, and they kill more people on average by doing it.
BitTorrent started in 2001, so more than 2 decades.
Very different use case. It seems both too heavy weight and not capable enough for e.g. sharing a screenshot or PDF from an Android phone to a Linux laptop without Internet connectivity.
Arguably, only in BitTorrent V2, which released in 2017, wasn't supported by major clients until 2020, and is still not widely adopted.
The same reason universal healthcare and free education is not widely adopted in the US. BitTorrent is quite “widely adopted” in other parts of the world.
> Bittorrent V2
This isn't always encrypted, right?
I think it's because of all the NAT, which makes any attempt cumbersome for a lot of people.
If only IPv6 had taken off...
If only they just made a new IPv4 with a longer address field, instead of something way more complicated that also changes pre-existing addresses.
100% correct!
Biggest mistake ever was not to grow it organically/incrementally while maintaining backwards compatibility!
XKCD from a decade ago, and we still can't figure it out ;(
https://xkcd.com/949/
Recently I had to send file from Whatsapp to Telegram, because apparently it is forbidden to download file from the Whatsapp and it's a "feature". Facepalm....
PS: afaik IPFS doesn't guarantee file storage, a separate paid middleman is required for that.
IPFS allows you to store your file and share the content ID to someone else so that they can get it through P2P
I did the same thing a long time ago, though I cant brag about using as long a list of frameworks, source is https://github.com/DusteDdk/fileswithafriend so you can host it youself, announcement post and link to site where it can be used is here https://news.ycombinator.com/item?id=39622511
In my version, the entrypoint is not uploading your file (where would it go??) but establishing the connection between two devices, then bidirectional transfers between them.
I really like PairDrop https://github.com/schlagmichdoch/PairDrop
Thanks for sharing!
Most other solutions don't allow pairing of devices across networks.
TFA's "file.pizza" only allows to initiate a session on the device that uploads a file, which makes it tricky to share a file from a mobile device to a laptop (due to tricky QR code scanning with the laptop camera).
PairDrop allows cross network pairing (mobile device can scan QR code from laptop screen), and file uploading from both sides afterwards.
Heh, seeing PairDrop motivated me to make sth similar, but more as a toy/exercise in messing with idiosyncratic/home cooked software: https://sonnet.io/posts/reactive-hole/
There is also Magic Wormhole [1] which is not in-browser.
[1] https://github.com/magic-wormhole/magic-wormhole
And https://github.com/psanford/wormhole-william which is a Go reimplementation of the client. I only want to point this out specifically because an apt-install of magic-wormhole on Ubuntu 24.04 actually results in a program that does not work (the beauty of python dependencies at play?)
It's really amazing to me how successful Python has been given its dependency management and package installation tooling
Pretty sure the snap version of wormhole works. I use it from time to time as well as the go binary.
If someone has ported the server I'll run my own instead of taking the bandwidth.
There is: https://wormhole.app/ for the browser if one needs it.
Other readers, please do note that (the unfortunately named) wormhole.app is unrelated to the frequently recommended, heavily peer-reviewed and much longer-standing magic-wormhole.
exactly!
Was just looking for such comment because I knew about wormhole.app is not on top of wormhole protocol itself.
Thanks for your comment , may it help other people.
Didn't knew that. Thanks a lot!
Not to be confused with https://webwormhole.io/, which is open-source
If having someone intall transmission (or your favorite torrent client) is not a hurdle, I like the privtracker approach a lot : https://privtracker.com/
The reason I like it more is that most torrent clients can run in the background by default so it's not dependant on keeping a browser tab opened
It made it to the frontpage not so long ago but it'd be a pity if you had missed it
FWIW I tried this the other week and it did not ‘just work’.
It just did nothing.
Then I remembered I have Syncthing running on the machines I was trying to transfer between, so I used that.
Ignorant question: isn't WebRTC just... built into the browser? Do you really need a stack of 20 things to tell the browser to connect to another browser with WebRTC? Isn't one HTML page with a few lines of javascript enough?
This is actually a good question for you. You have a multiplayer browser game and you want to swap out the websocket you’re using for webrtc. What all would that change involve?
Oh i love the use of webrtc for this, thank you for sharing!
This was my half day covid project to share file... inspired by firefoxsend a while back...
https://www.relaysecret.com/
the infra is super lightweight and you can deploy yourself with aws account, it costed me nothing to run and quite useful when needed :)
Nice! This uses server-side storage though, right?
That is correct and s3 are in 3 different regions with object lifetime of maximum 10 days, it is backed by s3, the idea is to have the simplest code for anyone to review what it does (encrypt in browser and send encrypted blob to s3, key never leave browser)
Also no 3rd party JS, no tracking etc..
These are neat but... it's 2025, and there is still no first class standardized ways to move files over the Internet between PC/mobile/edge devices.
This is my constant frustration with phones.
I sit behind a keyboard, mouse, monitor, and an incredibly powerful desktop operating system for 99% of the working day. These devices are pretty much the pinnacle of human-computer interaction; arguably the best tools we have for interacting with digital content with speed and efficiency.
But as soon as I want to do something involving my phone, I have to physically reach for it and immediately hamper myself with its limited UI, screen size, and ludicrously locked-down ecosystem limitations.
Smartphones have been around for decades and yet we're still nowhere close to seamless integration with the rest of our devices. The best we've got are clunky half-featured workarounds (Airdroid) or overly-complex techy solutions inaccessible to laypeople (VNC).
As another commenter said, it's all very much intentional. It's a deliberate choice on behalf of greedy phone manufacturers and greedy app developers. And it's really, really frustrating.
If you're on Windows I highly recommend Link to Phone
Link to Phone sends all your data (Messages, calls, notifications) to Microsoft. It also requires a Microsoft account. Admittedly for file transfers it's a bit different, if you're on the same network it will attempt a direct connection so MS won't get your files. It still sends the meta data (file names, file sizes) to Microsoft, though.
Similar issues with Smart Connect from Motorola.
An entirely local solution like KDE Connect is better, if your situation permits it. Unfortunately it has been quite unreliable for me (and I have tried many devices) but it seems to work just fine for others!
KDE connect solves most of these problems.
That's on purpose.
Imagine being able to just send a file from an Android phone to an iPhone without a centralized service and an Internet connection (i.e. like we could in the time of feature phones and early smartphones via Bluetooth)...
Please think of the shareholders and the lawful interceptors before you suggest something as subversive!
There's a dozen apps that will open an FTP server on your phone, then the other phone connects over the network with any FTP client.
Where do you get the FTP client and server from without an Internet connection, and how do you create a network between the two?
And would you say that this is comparable in terms of complexity with e.g. Airdrop or selecting "send via Bluetooth" and picking the recipient's device name?
> Where do you get the FTP client and server from without an Internet connection
Until last year, your web browser will usually download files. These days, you have to start an HTTP server. Which is actually easier, because FTP is a messy protocol.
> how do you create a network between the two
WiFi Direct has been built into phones for at least a decade.
> And would you say that this is comparable in terms of complexity with e.g. Airdrop or selecting "send via Bluetooth" and picking the recipient's device name?
On the sender side, the "send via" option can appear in the standard sharing app list. On the recipient's side, you may need to scan a QR code to finish the WiFi Direct connection. Starting the download should be as easy as having the sending app pretend to be a WiFi login portal so the phone automatically pops up the web page.
But if you're just sending files offline, there's always Nearby Share or plain old Bluetooth if the files are small enough.
> On the sender side, the "send via" option can appear in the standard sharing app list.
Can, but does it? Defaults matter. And how would the receiver be notified that they should download some file via FTP?
As long as such a feature does not come preinstalled on smartphones, I'll continue considering this lack of previously commonplace functionality an intentional vendor lock-in.
>how would the receiver be notified that they should download some file via FTP You tell them "hey I want to share a file with you, scan this QR code". The QR code sets up the WiFi Direct connection, the fake portal login should auto-open a "click here to download" button (or redirect to a file, but I don't think that's allowed), and once the file is downloaded you terminate the Wi-Fi Direct connection.
But that presumes phones don't have a method to share files. They have that feature built in. It's called Nearby Share on Android and AirDrop on iOS. Both use some weird pairing mechanism and some form of Wi-Fi Direct to transfer files, but the interface is just a bit more integrated.
When Apple opens up Airdrop or when Google convinces Apple to pre-install Nearby Share, we'll get the universal file transfer we desperately need.
What about people who have never heard the term "FTP" and don't know what a client or a server is?
Nobody cares what we do, we know how to use our computers well, and will force them to do what we want them to do in ingenious ways, and we will share those ways with each other. The problem comes when one of us puts that solution into a user-friendly mobile package that can be installed and run with your elbow, and then somebody makes a tiktok about it.
That app is getting nuked. Maybe even the internal API that enabled that app is getting nuked. If it's a standard protocol, it's getting extended and extinguished. The people who made it and the people who host it are getting legal letters.
Honestly yeah, AirDrop is part of Apple's lock-in.
Absolutely.
The fact that Google and Apple could quickly agree on a standard for both cross-platform Covid contact tracing and "stalker warnings" for "Find My" trackers, but not for cross-platform encrypted text messaging or an interoperable AirDrop extension, shows that it's purely a problem of incentives.
Maybe there's a way to send messages/files over the covid19 protocol.
> no first class standardized ways to move files over the Internet between PC/mobile/edge devices
FTP? You can open an app on your phone, start an FTP server, use UPnP to poke a hole in the router, show their public IP address, send a text message to your friend with the IP, port, username & password in a single URL, connect, send/receive files.
I meant modern -- you can use FTP over stuff like ZeroTier or Tailscale but otherwise you can't do P2P with it (firewalls, V4 NAT) and it's not secure. TS has some facility for transfer but again-- TS-specific, not available everywhere, not standard, and not suitable for all cases.
I also meant things regular people can easily use and that can be used as conveniently as e.g. Apple's AirDrop (which is nice but only works between Apple stuff).
It's part a UI/UX problem and part a missing standards problem. The latter precedes the former.
> firewalls, V4 NAT That's why they added 'use UPnP to poke a hole in the router'. Which will work on most networks, though CGNAT will still break it if IPv6 isn't available.
There are plenty of other tools out there that can send files between devices. Google+Samsung's Nearby Share work pretty much everywhere. KDE Connect works on any device I can think of. I wish Google+Samsung would make it an open standard but I'm guessing they won't do it so they can rewrite the app whenever they please.
The biggest, and IMO only, problem for AirDrop competitors is that they're not pre-installed on iPhones and iPads while AirDrop is. AirDrop is nothing special in itself, though Apple did implement it in a rather weird way. All you need to mimic it is Bluetooth (BLE if you're fancy) for handshakes and WiFi Direct for transfers.
This is the same predictable reply as the naysayers at the launch of DropBox. Both of us know that expecting people to set up FTP is a complete nonstarter.
https://news.ycombinator.com/item?id=8863
Has anyone used this kind of technology to create a kind of one-on-one messaging system that maintains a persistent thread (in browser storage) which can sort of simulate "texting" but without the phone?
Very nice. It reminds me of a similar all-in-browser file transfer tool I built ages ago called nearshare. This was WAY before webrtc was a thing so my approach was to actually run a web server in the browser via a java applet. :)
https://martiansoftware.com/nearshare/
>>The approach was simple, but relied on technologies that are now obsolete.
Does obsolete mean deprecated or removed?
First the one, then the other. :)
It used LiveConnect[0] to talk to the UI-less java applet[1] hosting the web server. It was a weird (and therefore kind of fun!) combination.
0: https://en.wikipedia.org/wiki/NPAPI#LiveConnect
1: https://en.wikipedia.org/wiki/Java_applet
I like https://github.com/schollz/croc
I love this WebRTC based attempt to send files browser to browser.
Too bad I’ve not yet seen it working without hiccups.
I’m currently testing keet, which is in beta but promising as well. https://keet.io/
I've also never been able to get these P2P web file transfer tools (FilePizza, ShareDrop) to work without issues. Transfers inevitably fail partway through, especially for large files. This seems to happen even in ideal network conditions such as over a LAN.
Keet is based on https://holepunch.to/ which I came here to say “Why don’t I ever hear about this around here?”
Holepunch is about open source tech for P2P apps without servers.
Thank you for the information.
For a simple no-frills alternative, I have this version on my site:
https://taonexus.com/p2pfilesharing/
I use https://blip.net which is like a cross-platform AirDrop, but also works over the internet in addition to LAN. Probably the fastest one I found.
Hey, our team made Blip! Glad you like the speed :)
I am intrigued by this. I read everything on your site. It looks great since it apparently allows transfer between devices using different OSes and that is always the sticking point around my place. I have several incarnations of Windows (7-11), a couple of linux distros (PopOS, CentOS7), and iOS on our phones. I see that linux is currently not supported though you would add that if people request it.
That's great.
My question for you is about the security of the data being transferred. You're using TLS according to your docs and this app transfers directly peer to peer. Is this secure FTP using TLS?
You have two tiers for users - Community and Business. Community is free and donations encouraged. Speeds may be slower to prioritize paying customers and support is more crowd-sourced. Business gets fastest speeds and direct support.
I am not a subscription buyer by choice. I would like to help make this profitable for you. Would you consider offering a paid version for personal use that would give faster speeds, security updates, and bug fixes at a price point between Free and Business? $300/year is way too much for something that would be used as a personal tool to quickly and securely send documents and photos to family members.
I realize that the donation model could function like a one-time payment model since you are likely using it intermittently and sending a small donation for each use so that your annual costs are minimized. In that case you always use the most current version. You "own" that version during the period that you use it and you pay a reasonable donation for use of it.
I also don't see the need to establish an account if this is a p2p service since the data transfers should walk from my device to the destination device. Fill me in on why I need an account.
I would pay for a license to use this with the expectation that the license would provide the current version of the app plus all bug fixes and security fixes for that paid version and that upgrades taking the app to the next full version would be discounted to existing users. I could be a long-term customer.
As an example, I use an antique, unsupported version of SnagIt on my machines. I purchased the license years ago, upgraded through a couple of versions until they got to a point where they dicked up the interface and changed the tool availability and so I ditched the newer version and have continued using the old version which work great. I still get the nag screens to update to the new version but the click to close that dialog is now muscle memory for me.
I appreciate the functionality that this app, blip, provides and would like to be a paying customer and use the app but I'm not interested in a subscription model.
EDIT: I forgot to note a slight error in one of your replies to a FAQ.
Under the "Blip vs Aspera" comparison in the FAQ "Why is Blip easy to use?" there is a fat-finger spelling error.
The sentence reads:
> We want you to set up any use it by yourself!
I believe that it should read:
We want you to set up and use it by yourself!
Hey, really appreciate such thoughtful reply. I’ll address your questions while explaining our design decisions and how Blip works.
We set Blip to use email addresses because we wanted to make it convenient for people who are less tech savvy and for business customers who need to quickly find and know who they’re sending files to. If you sign in on another device, all your other devices and recent people are just a click away—so you don’t need to set up or sync that list by yourself.
Blip is a local-first app in the sense that it works with files on your devices, but the interactions are server-driven, letting you negotiate transfers with your devices and other people, no matter where they are. When transferring files, we try to connect devices directly over IP, but when that’s not possible (and it often is not) we relay files over our servers. We use TLS 1.3 to encrypt files in transit. When devices are connected directly, we use mTLS for an even higher level of security. We plan on adding full E2EE in the future.
We care a lot about speed! We don’t throttle transfer speeds when devices are connected directly. Sending files on home Wi-Fi should be as fast as possible, as long as devices can ping each other. Reduced speeds only apply when using our relay network. If demand is high, business customers get priority to ensure their work is delivered on time.
Our business model is still very much evolving. Our main goal was to structure it in a way where people who benefit from Blip commercially should be supporting it the most. We considered a licensing model, but Blip relies on infrastructure maintenance and continuous development, so we need everyone on the latest and most secure version. We decided to make a clear distinction between community and business users, because we learned there’s more demand for speed at work. Of course, if community users start experiencing slow speeds (in practice, this hasn’t been the case), we’d love too bring this to personal users to. One way is for one-time donations to provide high-speed data boosts. Since personal users don’t require extra support and business features, pricing can be more affordable.
All that said, it’s so good to know that speed matters! Our goal has always been to make Blip the fastest way to send files.
Thanks again for the feedback, and for the heads-up on the typo—already fixed! :)
I suspect that I will give this a try on some of my devices. Thanks for the informative reply. I noticed that your Windows support begins with Win10. Does that mean that it won't work at all for Win7 or that it might not work?
I have a couple of Win7 workstations that could use something like this.
Ah, it likely won’t work since it requires Microsoft Store, which we use for certification and distribution.
That said, feel free to give it a try on newer devices. If you need any help, just shoot us an email.
Nice project and I always like playing with WebRTC but there is something that has me a little concerned .
> Transfers are now directly from the uploader to the downloader's browser (WebRTC without WebTorrent) with faster handshakes.
Maybe I'm wrong, but there is a signaling server in the middle somewhere along the chain here no ? unless it's just the same as PeerJS in which you first need the clients ID, but connection can be flaky.
From the source I can see it's using PeerJS but react is throwing me off a little bit. It's not clear to me what `useContext(WebRTCContext)` is..
Yes, this repo is also an api server which stores peer ids here `https://github.com/kern/filepizza/blob/main/src/app/api/crea... ` and here `https://github.com/kern/filepizza/blob/main/src/channel.ts`. Webrtc implementations typically use a server to connect peers. Without, peers need to exchange id’s to connect.
Is it strange that non of these ever worked for me over the years in different places/setups? (between windows/linux/osx). Literally never. Always been thinking of writing my own… I guess thats why there are so many :p
There must be dozens of services like this (ie. peer to peer file sharing over webrtc), but I can never get them to work. Presumably it's because often times one or both of my devices are behind strict NAT, and the service doesn't provide a TURN server (understandable, given that it might be bandwidth intensive). Does anyone know any public/self-hosted service that provides a TURN server?
We tried something similar 17 years ago. We couldn’t achieve true P2P, but we managed to relay a data stream via a server without store-and-forward. The startup was called Pipebytes, and we even got a bit of news coverage: https://www.youtube.com/watch?v=ATqKvra1X3o
It was later sold to another company, which scrapped the P2P part and repurposed it for regular cloud sharing. :(
Which browserbased p2p file transfer tool works with STUN and TURN servers? and if possible, also with an cli option?
Why can't we have a mixed system? A Dropbox like service with built-in file sharing. If there are no other peers or the speed of transferring from peers is slow, you use some servers for seeding.
I came across this recently while looking at cosmopolitan lib stuff https://bob.osau.re/
Idk if this will replace the good ol' snapdrop / pairdrop
Cool concept, has been done a few times before. Would prefer to see a cleaner implementation. Do projects like this really need Tailwind, TS, React? I don't think so.
I don't see which use case this is solving that hasn't already been solved by multiple other P2P file sharing browser based software available.
This particular project has existed for a decade. Any file transfer service which survives that long is worthy of praise, especially now when open-source solutions are being gobbled by LimeWire.
Local First Software benefits heavily from p2p solutions like these that can be integrated into a larger application
Isn't this easy to do with just WebRTC? Like, a few lines of code and using some signaling server and relay (STUN + TURN)?
is there any tool for p2p audio? something to communicate with friends while gaming would be cool
Jami[1]?
[1]: https://en.wikipedia.org/wiki/Jami_(software)
I appreciate every single attempt at solving xkcd #949, but so far, all I'm seeing is an ever-growing pile of evidence for #927.
It still needs middle out compression imo
WebRTC is compressed, unless I misunderstand your possible term of art “middle out“?
Middle out compression is what the guys in the TV show Silicon Valley invent.
lol ok.
Silicon Valley TV show
That's the beginning of The New Internet.
"Uh...the answer's not in the box, it's in the band".
Love that movie.
> He said, uh, "The answer's not in the box, it's in the band."
Didn't work here.
The downloader connects, status becomes Ready, then nothing happens.
Tried on both Firefox and Chromium.
It's a start to something great. Keep it up!
kids these days...
in my time, we used to know each other's IP addresses and just used netcat
In my time, we used to bring floppies to the schoolyard and just swap them.
We swapped cassettes and then copied them in hillbilly double cassette deck.
Making sure to cover the write-protect holes on the top with Scotch tape, of course.
In my time we just wrote very small on scraps of paper or tore pictures from magazines. We folded them tight into a compact rectangle, then we folded that rectangle across a rubber band between our thumb and index finger and with the other hand we stretched that rubber band enough so that when released, it would propel the folded rectangle of paper across the intervening distance rapidly enough that the adversarial player in the room could not detect the source or recipient of the rectangle without querying the entire congregation.
This method eliminated potentially adversarial middlemen in transit who might, if you chose to pass it through multiple players (servers if you will) - read it in transit though the message was not intended for them, and then use the contents against you later.
It had the disadvantage that one needed to insure that the sender and recipient were in sync in case the aim was off and the message bounced to an unintended recipient.
I once had the misfortune of sending a tightly folded, secure message that was part of a war game being played during English class, and having that poorly aimed message hit the largest mass of muscle in the class right squarely in the ear because the recipient was busy gloating over the success of their previous move and wasn't able to secure the reply in transit.
We all heard the light snapping sound of the rubber band followed by an uncharacteristically loud profanity from the unintended recipient, my own barely stifled gasp of horror, lots of giggles and laughter from the audience, and as they turned - the beginning of the next round of the Inquisition by the adversarial instructor who mistakenly thought we were all watching the English lesson on the board in real time instead of conducting paper war games in the background.
Fun times.
If that counts then you can use a flash drive and the problem is solved.
> In my time, we used to bring floppies to the schoolyard and just swap them.
Sneakernet!
"It's peer-to-peer, trust me bro!" The problem is that you are still using a website provided by a third-party to serve you the JavaScript program that initiates the transfer. It's easy to replace that JavaScript by something that just transfers a copy to the third-party itself. To be sure that the transfer is actually peer-to-peer, either the sender or receiver should run their own fillepizza server (and have verified that the source code does not contain any backdoors or phone-home code). But if you do that, you actually don't need a peer-to-peer solution anymore, it's turned into a client-server problem.
Ideally it's all a single html file that both sides can just open locally, no HTTP servers required.
Uses WebRTC, so not actually p2p.
>FilePizza eliminates the initial upload step required by other web-based file sharing services
homepage is an upload interface..
hmm, it says "Drop a file", not "Upload", on this step it uploads the file to your local browser for sharing, but the file is not actually uploaded anywhere on the outside
Relevant xkcd: https://xkcd.com/949/
I miss dukto r5.
That's great
>filepizza
Horrible name dude
i like the name. pizza invokes thoughts of sharing anyway
As someone who had the misfortune of moderating a platform with filesharing features, I agree that the name is... really bad.
(Cheese) Pizza is slang for CSAM.
https://www.urbandictionary.com/define.php?term=Cheese%20piz...
Wow I had no idea. Yeah then this is absolutely the worst possible name they could've picked.
Hopefully this isn't a "they knew what they were doing" situation
It's rather sus
Also, un-fun fact and coincidence... Peter Bright, formerly of Ars Technica and arrested for Child Enticement, had the nickname of "Dr. Pizza" on the Ars forums.
I wish I was joking.