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

191–200 of 272 posts

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

#191

Post by jen729w »

cassepipe wrote: post #147

If having someone intall transmission (or your favorite torrent client) is not a hurdle, I like the privtracker approach a lot : https://privtracker.com/ The reason I like it more is that most torrent clients can run in the background by default so it's not dependant on keeping a browser tab opened It made it to the frontpage not so long ago but it'd be a pity if you had missed it

FWIW I tried this the other week and it did not ‘just work’.

It just did nothing.

Then I remembered I have Syncthing running on the machines I was trying to transfer between, so I used that.

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

#192

Post by tripflag »

latexr wrote: post #190
tripflag wrote: post #186

Earlier quoted context omitted.

> There are services which allow you to upload via CLI and download via web browser, but they host your file so you have to wait for the full upload to finish before sharing the link. There are exceptions to this; I've been making copyparty[1], an httpd which lets you start downloading a file that is still being uploaded[2]. If you catch up with the uploader, it'll throttle the speed so the browser doesn't drop the c…

> copyparty Great name! Unfortunately this seems like it’s something I’d need to host myself, and that’s something I specifically don’t want to do. I only need to share on occasion, and always want to do it with the least hassle possible.

Yep, and the server bandwidth can become a bottleneck if the peers are fast enough, so true peer-to-peer is still the better choice, or something webtorrent-based if multiple people are grabbing the same file.

But there's been enough last-minute submissions of DJ material by now that I'm still happy it was added as an option :-)

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

#194

Post by makeworld »

latexr wrote: post #151

The thing that usually annoys me about these services is they tend to give you an intractably complex URL to share with the recipient. This poses a problem because every time I need such a P2P transfer, I’m communicating with someone over the phone and they need the file on a computer (which may not even be their own, so email is also cumbersome). https://file.pizza does this better than most, as the URL consists of…

> initiate a connection via CLI and get a simple URL to share

https://webwormhole.io does this, see the CLI link at the bottom. Just tested it myself with a small file.

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

#195

Post by makeworld »

j_maffe wrote: post #87
amelius wrote: post #8

It's so strange that this should have been a solved problem decades ago, but somehow a robust and secure non-commercial solution never gets off the ground. Speaking of which, how is the IPFS project doing these days?

IPFS is in this weird state where it's getting barely enough updates and enough usage to not be considered vaporware.

It is partially being succeeded by Iroh.

https://www.iroh.computer/

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

#196

Post by gruez »

There must be dozens of services like this (ie. peer to peer file sharing over webrtc), but I can never get them to work. Presumably it's because often times one or both of my devices are behind strict NAT, and the service doesn't provide a TURN server (understandable, given that it might be bandwidth intensive). Does anyone know any public/self-hosted service that provides a TURN server?

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

#197

Post by jech »

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

The Galene videoconferencing system https://galene.org> includes peer-to-peer file transfer. The web client is built in, but there's also a command-line client at https://github.com/jech/galene-file-transfer>.

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

#198

Post by nikisweeting »

saurik wrote: post #173
eptcyka wrote: post #152

Earlier quoted context omitted.

Both clients send a packet to a server, server sends the remote IP to both parties, both parties try to send traffic to either’s remote IP. Unless their nat firewall is evil, this should work.

That doesn't work with "symmetric" NAT, which was specified by the person you are responding to: in that case, you can't rely on even a third party to figure out the port. To the extent to which this NAT paradigm is chosen for its efficient usage of ports, this is fixable using UPnP/NAT-PMP/PCP, but 1) I've (sadly) never seen a WebRTC implementation which takes advantage of these protocols, and 2) usually this isn't…

CGNAT is increasingly common for large ISPs as IPv4 gets expensive.

There are entire regions of brazil where all residential internet is CGNAT'ed, making any video calls between those users symmetric NAT.

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

#199

Post by nikisweeting »

gsliepen wrote: post #183

"It's peer-to-peer, trust me bro!" The problem is that you are still using a website provided by a third-party to serve you the JavaScript program that initiates the transfer. It's easy to replace that JavaScript by something that just transfers a copy to the third-party itself. To be sure that the transfer is actually peer-to-peer, either the sender or receiver should run their own fillepizza server (and have verifi…

Ideally it's all a single html file that both sides can just open locally, no HTTP servers required.

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

#200

Post by filleokus »

gloosx wrote: post #141
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…

TURN or STUN server can use the DTLS transport in order to encrypt the traffic. So you know it's secure if you are using turns:// protocol and verified the certificate just like it works with https:// https://datatracker.ietf.org/doc/html/rfc7350

Hmm. I'm not a WebRTC pro but looked into it recently for a hobby project and felt that the typical WebRTC TURN implementation still leaves the TURN server in a quite trusted position. My rough understanding:

- (1) Each client generates a key pair

- (2) The fingerprint of the public key is part of the SDP message each client generates

- (3) The SDP message is somehow exchanged between the clients, out of band, and the session is started. The client's verify the remote peer using the public key from the SDP message.

The problem is that it's not really feasible in most circumstances to exchange the full SDP message out of band, so instead the service provide some mechanism to map a shorter ID (typically in a URL) to a centrally stored copy of the SDP. I think this might be where it happens for filepizza [0].

This means that a malicious file sharing operator, being in control of both the TURN service and the out-of-band signalling mechanism, could just MITM the DTLS connection and snoop on all the data going by. The peer's think they have each others public keys but they just have two keys owned by the server.

[0]: https://github.com/kern/filepizza/blob/main/src/channel.ts

Post reply on HN