Hopefully it's not also using TURN servers if STUN fails...
How is this even close to being "no server involvement"? It's misleading, because the server is very much involved here.
> But I suppose that would be basically impossible on today's internet.
P2P is possible on the internet (100% without centralized servers), but it's not possible without STUN/TURN on the web.
Have you looked at the actual payload of the POST/GET/PUT requests? It only contains the WebRTC offers/answers. Actual file transfer is via local WebRTC.
The site also claims that it only work for "devices on the same network", so there's no need for any STUN/TURN because there's no wall to punch.
It's like saying you can connect to a domain name like google.com with no DNS involvement, because you only get the address and then the connection is over HTTP.
> So not really "no server involvement".
and capableweb said (3 posts up):
> How is this even close to being "no server involvement"? It's misleading, because the server is very much involved here.
No one said the file was being sent through the server, that's your own reading of it. You are entitled to your opinion but don't tell people off about "no one said this" or "what's being discussed", it's just rude.
> Not even, the application is making GET, POST and PUT requests to send the file to a /link endpoint
Capableweb definitely said the file is being sent to the server. Not sure how much more literally that could be said, in fact. You somehow managed to quote the second line of that comment (some might say "cherry pick") while completely missing the first line where they explicitly said what it was claimed they said. Genuinely not sure if you're being deliberately misleading or have some of the worst reading comprehension I've seen on the internet.
If you and Kiro could just recognize that different people can understand that sentence in different ways, we wouldn't be there, but instead you like to proclaim that "no one is saying anything about" and "what's being disputed is" and other "that other person definitely said"
I can see how I'm expecting too much of you. You have a nice day now, though I'm sure it will be full of people not understanding things exactly as you do.
This isn't some ambiguous statement that is open to interpretation. They literally said the file is being sent to a /link endpoint. What part of that statement of you struggling to parse?
> uploading happens by doing a POST request to the server, and fetching happens by doing a PUT request, not sure why people keep re-iterating that it's probably WebRTC when it's really not, this is just a very basic, centralized server that does the receiving/sending of the file
Getting P2P connections working reliably is an effort in edge case discovery and either fixing it or falling back.
Assigning public IPv6 addresses to every device in your home just pushes the "deny" rule to a slightly different part of the network stack. We will still require something similar to STUN to get around firewall rules.
If you can get around the firewall rules with something like STUN then those rules aren't really doing you much good, are they? By all means, put random IoT devices on a separate VLAN and block all incoming connections directed there (without UPnP). And be sure to block all the obvious workarounds like STUN for that VLAN or there's no point in having the firewall. But for PCs, smartphones, and the like it should be possible to connect to their open ports from outside the network using their public IP addresses without any tweaks at the router. These devices are perfectly capable of securing their own listening ports.
Bittorrent works just fine here.