Snapdrop – AirDrop equivalent through a web browser using WebRTC
snapdrop.net
snapdrop.net
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...
You could also scan a LAN's entire subnet for machines with this: https://github.com/jdfreder/pingjs
It would have been beautiful if the discovery could have been purely client-side though.
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...
Maybe Snapdrop can do something similar with the new Bluetooth Web APIs.
> 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.
It does need a network, that's why it creates one using an ad-hoc WiFi connection.
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].
Other such services shared on news.yc previously: https://drop.lol, https://lbry.com, https://webwormhole.io et al [3][4][5].
Just a reminder that, WebRTC doesn't leak your public-IP if you're behind a VPN [6].
--
[1] https://news.ycombinator.com/item?id=19603947
[2] https://tools.ietf.org/html/rfc8445
[3] https://news.ycombinator.com/item?id=17356023
[4] https://news.ycombinator.com/item?id=22273674
I agree with the sentiment: Why is this so hard in 2020? Normally, by now, we would have routed around the damage.
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.
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.
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.
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. `
I've made a library that uses WebTorrent trackers to exchange the signal data and make P2P connections : https://github.com/subins2000/p2pt
EDIT: After a few minutes with a black screen it started transferring.
EDIT 2: The transfer was suddendly canceled.
Merry Christmas from Germany!
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.
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.
> 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.
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.
[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)
Does anybody know how the discovery mechanism works?