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.
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.
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)
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?
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.
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.
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.
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.
`
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.
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.
"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.
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.
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.
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, ...)
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.
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.
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.
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.
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.
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
İ 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.
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.
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
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.
154 comments
[ 2.9 ms ] story [ 201 ms ] threadOk, 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...
It would have been beautiful if the discovery could have been purely client-side though.
You could also scan a LAN's entire subnet for machines with this: https://github.com/jdfreder/pingjs
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.
...but they haven't done so.
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.
> You can be discovered by everyone on this network
Assumption here being that the devices on the same network are all NAT'd behind the same public IP, which usually holds true.
See the server code for designating rooms & peers: https://github.com/RobinLinus/snapdrop/blob/master/server/in...
Can also test that there is no "discovery" beyond public IP grouping by turning off wifi on your mobile and joining from mobile network.
They need some good PR on that feature.
"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.
It's pretty similar to what you describe.
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.
You are free not to trust them. But I do.
By sharing your key between the devices.
> a legal order in any single jurisdiction only decrypts one layer of encryption
That's good to know, but it's not the cutting edge of security. (For many people it's of course enough)
> They also offer end-to-end encrypted secret chats
Not on desktop and not on GNU/Linux phones (which I use).
That would be a nice feature.
> but it's not the cutting edge of security.
That's true.
> 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. `
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.
Super slick between the two that do work, though!
Sounds like my experience with Apple's regular Airdrop :) but to be honest, it's been quite some time since it failed me.
I've made a library that uses WebTorrent trackers to exchange the signal data and make P2P connections : https://github.com/subins2000/p2pt
Small nitpick about the wording of this:
"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.
If a server is needed anyway, could it be implemented in easier, OpenWRT-compatible way?
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.
It uses WebTorrent trackers and is easier to setup offline on network.
https://github.com/subins2000/WebDrop
[1]: https://github.com/mustakimali/just-an-email
[0] https://github.com/DanielGilbert/just-an-email
[1]: https://sharedrop.io
Some feedback; I have an iPhone and Firefox running on Ubuntu; they could find each other, but the iPhone couldn't send files to the Firefox instance.
It did work with Chromium though (which was very cool)
URL: https://symmetric-crypto-chat-room.herokuapp.com/
Repo: https://github.com/amir734jj/SymmetricCryptoChatRoom
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.
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!
There was talk.gg which is exactly what you're looking for, but I see it's been down for a few years now.
https://meet.jit.si
Maybe Snapdrop can do something similar with the new Bluetooth Web APIs.
It does need a network, that's why it creates one using an ad-hoc WiFi connection.
> sets up an ad-hoc WiFi connection
> No network required
Guess we have different definitions of what a "network" is. I'd call that a network, of two devices.
Cloud drives (iCloud, OneDrive, GDrive) are all too slow on bad WiFi.
This should help me.
the ONLY thing that's worked for me is syncthing -- I can't copy files over USB reliably at all.
I guess I could also pay for google photos but honestly fuck google so much. I have a pixel 3a so all I get is the unlimited low-res images.
Why the hell this thing can't just backup files over USB or SMB or a card reader/USB drive plugged in to usb-C is beyond me.
[1] https://en.wikipedia.org/wiki/Network_address_translation [2] https://en.wikipedia.org/wiki/STUN [3] https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_...
About 33% of folks have IPv6 connectivity now, up from 5% in 2015.[1]
The NAT problem isn't going away anytime soon, but it's good to see some progress is finally being made on that front.
[1]: https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6...