Peer-to-peer file transfers in the browser • Hacker News Board

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

#201

Post by jjk7 » Wed, Mar 12, 2025, 9:50 PM UTC

pjc50 wrote: post #43

SirMaster wrote: post #37

Earlier quoted context omitted.

I think people mean something seamless like AirDrop is on Apple devides, but some public standard that gets implemented on all platforms like iOS, Android, Windows, macOS and Linux, so all these platforms can just easily send files to each other simply and securely over WiFi.

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

The DHT exists, all you need is an infohash and you get grab the metadata from peers/uploader.

libtorrent supports something called 'SSL' torrents that require both peers to be signed by the same root.

All the pieces are there to build on top of.

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

#202

Post by deknos » Wed, Mar 12, 2025, 9:53 PM UTC

Which browserbased p2p file transfer tool works with STUN and TURN servers? and if possible, also with an cli option?

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

#203

Post by latexr » Wed, Mar 12, 2025, 10:14 PM UTC

makeworld wrote: post #194

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.

This does look quite close to what I wanted. Thank you. Unfortunately, it also looks to no longer be under development.

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

#204

Post by eptcyka » Wed, Mar 12, 2025, 10:15 PM UTC

nikisweeting wrote: post #198

saurik wrote: post #173

Earlier quoted context omitted.

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.

What part of CGNAT requires the network address translation to be symmetrical?

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

#205

Post by polishdude20 » Wed, Mar 12, 2025, 10:20 PM UTC

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

A lot of cell networks won't work with STUN. I've tried in personal projects to have a home computer with wifi communicate through a stun server to a mobile device using mobile data. It don't work.

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

#206

Post by hot_gril » Wed, Mar 12, 2025, 10:24 PM UTC

lxgr wrote: post #169

hot_gril wrote: post #157

Earlier quoted context omitted.

Honestly yeah, AirDrop is part of Apple's lock-in.

Absolutely. The fact that Google and Apple could quickly agree on a standard for both cross-platform Covid contact tracing and "stalker warnings" for "Find My" trackers, but not for cross-platform encrypted text messaging or an interoperable AirDrop extension, shows that it's purely a problem of incentives.

Maybe there's a way to send messages/files over the covid19 protocol.

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

#207

Post by numpad0 » Wed, Mar 12, 2025, 10:41 PM UTC

filleokus wrote: post #200

gloosx wrote: post #141

Earlier quoted context omitted.

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

Only the initial SDP needs to be fudged. The attacker could just set up two clients that pretends to be the sender/recipient. Then the data can just go through regular Google TURN servers.

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

#208

Post by [deleted] » Thu, Mar 13, 2025, 12:24 AM UTC

culi wrote: post #101

supertrope wrote: post #89

Earlier quoted context omitted.

People drive one ton pickup trucks to commute to their desk job. Or to get two bags of groceries.

This is true but this sucks. Modern American SUVs are an abomination too. The American auto industry started pushing them because they're legally classified as "light trucks" which lets them take advantage of certain safety and environmental standard loopholes

[deleted]

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

#209

Post by frontfor » Thu, Mar 13, 2025, 1:19 AM UTC

eptcyka wrote: post #171

ranger_danger wrote: post #159

Earlier quoted context omitted.

That's no longer p2p, that's using a relay server like TURN

It is p2p, the middle server isn’t relaying traffic.

If TURN is used, then it absolutely is. Please read the comments above.

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

#210

Post by frontfor » Thu, Mar 13, 2025, 1:24 AM UTC

0xbadcafebee wrote: post #74

api wrote: post #48

These are neat but... it's 2025, and there is still no first class standardized ways to move files over the Internet between PC/mobile/edge devices.

> no first class standardized ways to move files over the Internet between PC/mobile/edge devices FTP? You can open an app on your phone, start an FTP server, use UPnP to poke a hole in the router, show their public IP address, send a text message to your friend with the IP, port, username & password in a single URL, connect, send/receive files.

This is the same predictable reply as the naysayers at the launch of DropBox. Both of us know that expecting people to set up FTP is a complete nonstarter.

https://news.ycombinator.com/item?id=8863