I would perhaps delay showing the funny name until at least one other machine is detected, it makes it feel like my name is being broadcast over the public Internet for anyone to connect to, and not just a LAN connection, the way it is.
But worked perfectly for me to send a few photos back and forth.
LAN connections seem like the perfect application for WebRTC not having to deal with TURN or STUN.
It is a bit unnerving that there’s no permission request before being able to do network discovery on the LAN however.
How is one machine finding the other? Central server matching the public IP used to then share their private IP? Or does WebRTC provide a discovery service?
Edit: Ok, Looking at the server code [1] there is indeed a “room” per public IP and the server passes messages between peers in the same room.
Although my plate is pretty full with projects I'm curious to know whether it's possible to implement a peer discovery service by consuming bandwidth in a modulated fashion and detecting those changes in bandwidth availability on another machine.
It's not really an AirDrop equivalent if it requires you to be on the same network. AirDrop is really useful when you're out and about somewhere and you want to send someone a file. In those cases there's possibly not a WiFi available or in the case of visitors to your home; only you are on the network, not your friend. So I would not see the point of using this instead of AirDrop unless you have to send a file to someone using Android.
İ have an Android and a MBP. The number of times where İ think, "why is this so hard to get this file to that computer" is more than I'd like to admit.
Cloud drives (iCloud, OneDrive, GDrive) are all too slow on bad WiFi.
I have the reverse problem (win10 devices/iphone) and it has become enough of an issue to convince me to switch to android. Its ridiculous how Apple treats non apple devices as third-class citizens.
How would you send a file using Android (without access to an already existing network)? I asked someone with an Android phone the other day and apparently it's not practical.
WiFi direct - so long as the connecting devices support it and there's no requirement to be connected to the same WiFi network. Works a treat transferring from Android to Android or Windows 10 and it isn't proprietary.
The fact that someone would have to Google how to do this is what Windows is lacking.
I built a hackintosh and bought an iPhone after I got tired of those disparities and disconnections. Why can’t Windows just work with Android already?
For Windows 10 yes, but for Android it's in the share context menu, so easy to use in fact that my mum and dad have been using it for years to send each other videos and pictures of trips and outings at blazing fast speeds, for them it's just magic as it works and they don't need to understand what's happening under the hood or fulfil any technical prereqs.
When sending, it should appear under the share menu when you share something and to receive you just need to go on WiFi direct which can be opened under the WiFi screen.
One option is to use X-plore, a seriously well featured file manager app for Android. If both devices are on the same wi-fi network, which I pretty much always am when I need to do this, in a couple of taps you can use its "WiFi file sharing" mode which lets any device with a browser address a file manager, view and download files. The docs don't really do it justice - https://www.lonelycatgames.com/docs/xplore/wifi-share/in-web
I use the VLC iPhone/iPad app to transfer files. There is an option to show the files on your iPhone/iPad as a webserver which works on any device that has a browser (you have to be on the same network).
Fair warning about this method: It will transfer the file just fine, it is depending on iPadOS recognizing there is a file somewhere else. If you are using it for watching video files, you will have to use VLC since iPad video app will not see the file. I tried to use the iPad to watch my video collection (Plex and Emby required paid app for streaming to the iPad), it does weird thing with them. Some of the video file (in MKV, encoded with various format [x264 and HEVC]) will load the video just fine, it will have problem seeking and missing subs (it is already in the container), dropped audios and stuff. I thought my video files is the problem and i tested them in PC and my Note 8, it ran just fine. I would believe it is something to do with iPad OS, PC and Android VLC played the video without issues.
Alas, this is a general issue with WebRTC: Most people are behind NATs[1], and not even STUN[2] can save them. In order for this to support internetwork (heh) transport, you'd need a TURN[3] server that could relay the traffic between the participants. Of course, at that point you're not really Peer2Peer anymore: You have a server between you and that server is going to cost actual money to run.
Definitely not true for me. My most common scenario is "can you please send me all the photos of the trip/dinner/... in the original resolution" in a car park/train station/street corner.
I suspect most people use AirDrop for the use case where a bunch of folks are physically somewhere together, perhaps on a trip or having coffee, and someone asks: "hey, can you quickly send me that video?". Without Airdrop that isn't always feasible: 1) a WiFi network may not be available to send using other means 2) perhaps the video is very large and would eat your data 3) no cell reception at all, as is common on adventure or hiking trips
To be fair, AirDrop requires you to be on the same network as well, as otherwise the devices don't have any way of communicating. If you're already on the same WiFi, it'll use WiFi but if not, it'll connect to each other via Bluetooth (eg, connecting to the same network [a network of two devices]), but the setup of the connection is automatic.
Maybe Snapdrop can do something similar with the new Bluetooth Web APIs.
False. AirDrop does discovery via bluetooth, but then sets up an ad-hoc WiFi connection directly between devices to transmit data. No network required.
That Airdrop sets up its own temporary network hidden from view is not really relevant to most users though. For the user, it just works like "magic". All you need are two phones.
That was the initial version of AirDrop that had the same network requirement; future releases negotiated an adhoc wifi connection over bluetooth then used that.
See https://file.pizza for a similar file sharing service, but over BitTorrent over WebRTC (not sure if it requires a relay TURN server when peers are behind symmetric NAT) [1][2].
file.pizza does not work between Win10 & android. Oddly, sending from W10, receive on android, when I enter the url into android, it successfully transfers the file name - but the actual file bits are 404.
I agree with the sentiment: Why is this so hard in 2020? Normally, by now, we would have routed around the damage.
It is a shame AirDrop is not an standard across all devices. It's almost 2021 and we don't have a universal way to share files in original format. Most ways to transfer between android/iphone/mac/pc are over the internet and compressed. I guess the industry is not interested in collaboration.
There is WiFi Direct, a standard which is supported by both Android (since Android 4.0) and Windows 10 (dependent on the WiFi card).
It's more of a case for Apple to support it on their devices.
Very true. I had high hopes for Google's "nearby share" which was initially announced as a cross-platform networkless way to share files, but these ambitions seem to have been scaled back to "Android to Android only, and it sometimes uses mobile data as a fallback"...
And it is works only with the contacts in a phone.
Most of the time I need to send a file from a company device and I have to add me to contacts in the shared testing device to make it work.
Which all works great if you serve all markets but my high end work was pushed off Apple because they literally didn't sell machines powerful enough (still don't), trying to get a 60fps 4K video off my iPhone and onto the high end PC to edit it was a complete nightmare I was lucky enough to experience recently.
File is too big for gmail,whatsapp,slack and all the usual gotos, my work Mac laptops hard drive is too small to airdrop there and transfer. Can't remember what my solution in the end was but the walled garden of iOS wasted over an hour of my time on a deadline.
On the other hand, if it's not working, there's absolutely no information about why not.
Seems fine between (firefox on ubuntu) and (safari on ios), but neither can talk to (chromium/bromite on e.os) and there's no error message or anything, just nothing ever shows up at the other end.
"Notifications permission has been blocked as the user has dismissed the permission prompt several times. This can be reset in Page Info which can be accessed by clicking the lock icon next to the URL."
I have Safari set to not allow websites to ask for notification privileges at all and did not see a single prompt. And I don't think you can toggle it from the lock icon.
It's not a SPA that can run without a backend, so no. Most of the clients will need to connect via the backend which is currently run at wss://snapdrop.net/server/webrtc. Without it, they won't be able to penetrate NAT and will be unreachable.
You and many others :) WebRTC (Web Real-Time Communications) is faux-P2P, in that in order to establish the P2P connection, you'll need a server in-between as browsers cannot accept incoming connections, you can only dial out and then start listen for replies.
> If a server is needed anyway, could it be implemented in easier, OpenWRT-compatible way?
I'm not sure why it would have to be OpenWRT-compatible? OpenWRT is just Linux run on less-powerful hardware (over-simplification obviously), so anything Linux can run, should be able to run on OpenWRT. Find your favorite STUN/signalling server and try running on OpenWRT, should work fine.
Interestingly, besides sharing files, you can also right-click a device to send a message to that device. It's fully encrypted end-to-end between points on your network.
"Saved Messages" looks like a private chat that only you can see. You can drop messages or files in there, or forward them there from other chats, and access them from any other device.
How could you access end-to-end encrypted cloud storage from multiple devices?
It's still encrypted, and in multiple jurisdictions so a legal order in any single jurisdiction only decrypts one layer of encryption.
"Telegram is a cloud service. We store messages, photos, videos and documents from your cloud chats on our servers so that you can access your data from any of your devices anytime without having to rely on third-party backups. All data is stored heavily encrypted and the encryption keys in each case are stored in several other data centers in different jurisdictions. This way local engineers or physical intruders cannot get access to user data."
https://telegram.org/privacy
They also offer end-to-end encrypted secret chats, which are not uploaded to the cloud and only available on the device on which they were initiated.
> Not on desktop and not on GNU/Linux phones (which I use).
That's unfortunate, but luckily the clients are open source, and anybody can create a new client for the platform of their choice. Telegram even provides a cross-platform API library: https://core.telegram.org/tdlib
`
TDLib can be used on Android, iOS, Windows, macOS, Linux, WebAssembly, FreeBSD, Windows Phone, watchOS, tvOS, Tizen, Cygwin. It should also work on other *nix systems with or without minimal effort.
`
I am working on an open source framework which connects nodes for collaboration and p2p transfer. I started off with WebRTC at the core but have since made it optional transport due to lack of portability. Snapdrop is amazing but if you give up on WebRTC you can use QR code for discovery and transfer files even when not on the same network.
Signalling through QR code or pen & paper while possible in theory is not feasible in practice because both sides need to exchange ICE candidates & offer/answer. So a signalling middleman, whether through websockets, SSE, polling, etc. is needed. And if you want to support network handoff then you need persistent connection to the signalling server for re-negotiation.
Yes, the first version is here: https://github.com/uhst/uhst-client-js and there is a demo Ping app: https://examples.run/ping/ . Originally my idea was to use SSE for signalling but in version 2 it becomes a relay between peers. This approach will make it portable to mobile (native, Flutter, RN) which is difficult to do with WebRTC. The added throughput and latency should be similar to using TURN server with WebRTC. Websockets are the more common choice for signalling but HTTP/2.0 brings a new life to SSE.
Hi, this does not work for me between W10 and android. How can I go about debugging this? Both names appear on both screens, but no files seem to transfer. I tried web & app on android, no difference. Thanks!
Is this any different to sharedrop.io, and how does it handle large files? I tried to send a zip file through sharedrop.io to my father and it just hung with no progress bar - so I had no idea if it was sending really or not. At least network manager showed only very slow upload.
I sent a 5GiB file from my android phone to my laptop, my phone hungs for nearly a minute before it starts the sending process. My hypothesis is that it needs some 'processing' from and to the browser and the phone storage.
Is there an audio chat equivalent of this? When I'm playing networked games with my kids from separate rooms, we often have to resort to overkill utilities like Whatsapp / Discord / etc.
Teamspeak (or ventrilo) used to be the way to go when I was into online multiplayer games (~10 years ago). Not in browser, but low latency and extremely low resource requirements (definitely less than one browser tab; we have tried Skype back then as well, but it was using too much recorded for the computers we had back then, especially if there was more than 2 people on the call). You could host teamspeak server yourself on your local LAN. Not sure if there is some easy discovery mechanism or you would need to know the local IP (and ideally set up static DHCP for the "server").
I imagine WebRTC might require some sort of server as well, so I don't think you can get something purely in browser on all machines, but if you learn about anything let me know!
It includes video as well but jitsi.meet works quite well. A dedicated audio chat server like Mumble/Murmur will probably beat any such solution in performance though.
Thanks for the tip. It works but it looks very heavy on the CPU. My fans started spinning not long after I opened the site (2014 MBP / Chrome)
What I would like is a dead-simple app equivalent to a walkie talkie. Self-hosted would be even better, in case we are using local wlan with no internet access.
I found tons of tutorials on how to create a WebRTC application, but strangely no ready-to-use solution.
On a similar note: I use [1] for sharing files, links etc. between two devices. Best feature for me: I can generate a qr code, scan that and be instantly connected - no matter which network I‘m on.
That is correct. Besides reporting a bug, I'm not affiliated with this project. Too bad GP doesn't know much about forking to tell the difference, but is fast enough to blame.
Not web based but I have used croc https://github.com/schollz/croc to send files between pc and laptop on same network and between two computers on different continents.
this is 100% the thing apple does that google absolutely refuses to de-intermediate themselves out of. apple allows direct bluetooth discovery, google 100% insists on closed proprietary "android nearby" systems to find local devices. neither release protocols or standards to interoperate on.
Why can't I Airdrop from my phone to my MacMini thats connected via ethernet cable. They are on the same network, and verified with other tools, but AirDrop has to be done over wifi for what reason?
Short answer is - Airdrop is a protocol for setting up ad-hoc wifi networks via Bluetooth LE. If it went over ethernet it wouldn't be airdrop.
Long answer:
Airdrop does discovery via bluetooth. To send a file, the two devices connect via bluetooth to negotiate the details of a new ad-hoc wifi connection, which they then create, connect to, and use for the transfer.
The discovery does not rely on a shared network, and once connected, the devices never 'discuss' whether they already share a network, so it's WIFI or nothing.
This gives some security guarantees that wouldn't exist otherwise. EG: Airdrop won't go through Starbucks' WIFI, even if both the sender & receiver are connected to it. Honestly I'm not sure how important those guarantees are -- but they're there.
I don't think there's a fundamental barrier stopping Apple from:
1. Having devices advertise an 'airdrop-box' through Bonjour as well as though bluetooth LE,
2. Including these entires in the Airdrop UI
3. De-duping entries where it figures out that a network device is the same as a bluetooth device.
4. Running same-network transfers through SMB rather than using [what they currently call] Airdrop to negotiate an ad-hoc WIFI network.
I believe the name for this ad-hoc network is Apple Wireless Direct Link (AWDL), though I think that the name also refers to the mechanism that allows one WiFi radio to be involved in doing AWDL and also not drop the connection to the WAP hosting the WLAN.
Because AirDrop doesn't use your local network at all, it creates a direct peer-to-peer wifi connection between the two Apple devices. It has no way to do that via an ethernet cable.
As someone said in a nested reply: you can. You don't need to be connected to anything via Wifi, but it needs to be on.
This isn't just theory: I use my Mac mini in exactly this configuration. Wired Gbit Ethernet, but with Wifi left on but connected to no network for airdrop/handoff/etc stuff.
this is an anti argument to me. you should be able to, over bluetooth. or maybe mdns, in some slightly better fantasy world. but this question distracts, picks foibled with airdrop, when a far greater scope question of why no one anywhere has low-intermediation direct device-to-device discovery. I don't care that Apple's implementation isnt perfect, doesn't work for xyz use case. no one else has any airdrop like basis at all. and there are no protocols or standards out there that begin to address this fault. everyone else is on square 0. terrible.
seems like it would cut into the market for "cloud". users would in some instances have no reason to upload data to remote data centers just to move files from one device to another. why doesn't every phone support wifi direct.
Similar to sharedrop.io [1] in name, user naming and appearance. The latter does allow sharing between users not in the same IP too, though. I am not affiliated with either.
this has been around for four years?! Awesome! Would like to see the faq more easily accessible for troubleshooting. Was not able to send jpgs the first few tries
It's just the signalling server to exchange ICE candidates. Once the connection has been made between two devices, the traffic is direct...unless they are on two different networks and/or firewalled, then you would need a TURN server to relay traffic through.
wow, nice. I connected using my phone (2nd device) and noticed that I was on 4G and switched to WiFi at that time and there was no hitches (1st device was discovered no problem)
I really don't understand HN's obsession with webrtc based file sharing tools. 1 of these is posted every 6 months or so, Every version of it is doing more or less the same thing and every time it gets to the front page and stays on it for a while. What's happening?
I guess they seem to solve a common difficulty (cross-device file sharing), but in the end they are not good enough to be widely adopted, and they get forgotten.
The main feature that's missing from all these services is: integration into whatever messaging application the user is already using (email, Whatsapp, ...)
Ok, that’s cute.
I would perhaps delay showing the funny name until at least one other machine is detected, it makes it feel like my name is being broadcast over the public Internet for anyone to connect to, and not just a LAN connection, the way it is.
But worked perfectly for me to send a few photos back and forth.
LAN connections seem like the perfect application for WebRTC not having to deal with TURN or STUN.
It is a bit unnerving that there’s no permission request before being able to do network discovery on the LAN however.
How is one machine finding the other? Central server matching the public IP used to then share their private IP? Or does WebRTC provide a discovery service?
Edit: Ok, Looking at the server code [1] there is indeed a “room” per public IP and the server passes messages between peers in the same room.
[1] - https://github.com/RobinLinus/snapdrop/blob/master/server/in...