[iCarrot]

>the application is making GET, POST and PUT requests to send the file

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.

[remram]

If those POST/GET requests are coordinating the transfer and exchanging metadata, "no server involvement" is still wrong.

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.

[Kiro]

No-one said anything about the "no server involvement" claim here. What's disputed is capableweb's comment that the app is sending the file itself to the server and not even using WebRTC, which is incorrect. They even say "checking how it works is trivial if you open up the Network inspector" but WebRTC traffic does not show up in there. So much for it being "trivial".

[remram]

Yes, they did. kelnos said (4 posts up):

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

[fastball]

This thread is devolving rapidly but:

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

[remram]

Yes, in order to send the file, the application is making GET, POST, and PUT requests. He didn't say the file was sent over the requests. We obviously understood this differently.

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.

[fastball]

> send the file to a /link endpoint

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?

[Kiro]

No, it's not a question of interpretation. You simply understood it incorrectly. Another quote from capableweb in this thread which hopefully makes this clear for you:

> 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

[meheleventyone]

Even on the same network you might need TURN. Browsers use mDNS addresses for local connections rather than leaking internal IPs and if your network doesn’t work with it then a direct connection will fail. You can disable this but it’s not ideal.

Getting P2P connections working reliably is an effort in edge case discovery and either fixing it or falling back.