Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Peer-to-peer file transfers in the browser

github.com

Post reply on HN
Print view View original

121–130 of 272 posts

Re: Peer-to-peer file transfers in the browser

#121

Post by Timber-6539 »

mhitza wrote: post #7
Rygian wrote: post #6

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?)

Pretty sure the snap version of wormhole works. I use it from time to time as well as the go binary.

Re: Peer-to-peer file transfers in the browser

#122

Post by SirMaster »

JadeNB wrote: post #57
pjc50 wrote: post #43

Earlier quoted context omitted.

"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 fa…

> 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.

Re: Peer-to-peer file transfers in the browser

#123

Post by saurik »

crazygringo wrote: post #99

> 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 E2…

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).

Re: Peer-to-peer file transfers in the browser

#124

Post by [deleted] »

lxgr wrote: post #118
0xbadcafebee wrote: post #76

Earlier quoted context omitted.

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?

[deleted]

Re: Peer-to-peer file transfers in the browser

#125

Post by jeroenhd »

lxgr wrote: post #118
0xbadcafebee wrote: post #76

Earlier quoted context omitted.

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.

Re: Peer-to-peer file transfers in the browser

#127

Post by d3rockk »

smusamashah wrote: post #45

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...

Bless you.

Re: Peer-to-peer file transfers in the browser

#128

Post by lxgr »

jeroenhd wrote: post #125
lxgr wrote: post #118

Earlier quoted context omitted.

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 complex…

> 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.

Re: Peer-to-peer file transfers in the browser

#129

Post by ivanjermakov »

modeless wrote: post #4

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.

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

Re: Peer-to-peer file transfers in the browser

#130

Post by [deleted] »

saurik wrote: post #123
crazygringo wrote: post #99

> 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 E2…

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).

[deleted]
Post reply on HN