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

131–140 of 272 posts

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

#131

Post by ranger_danger »

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

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

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

#132

Post by catlikesshrimp »

martylamb wrote: post #31

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?

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

#133

Post by IncreasePosts »

mary-ext wrote: post #5

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.

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

#135

Post by vzaliva »

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

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

#136

Post by ranger_danger »

eptcyka wrote: post #116
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…

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.

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

#137

Post by 0xdeadbeefbabe »

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

If someone has ported the server I'll run my own instead of taking the bandwidth.

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

#138

Post by jollyllama »

culi wrote: post #107
chmod775 wrote: post #90

Earlier quoted context omitted.

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

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

#139

Post by pnutjam »

j_maffe wrote: post #86
wackget wrote: post #82

Earlier quoted context omitted.

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…

If you're on Windows I highly recommend Link to Phone

KDE connect solves most of these problems.

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

#140

Post by ivanjermakov »

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…

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

Post reply on HN