5 ms·

Webcontent is not a free platform. It does not even give you sockets which can interact with arbitrary network services without centralized control (no, websock

by the8472 10y ago

Webcontent is not a free platform. It does not even give you sockets which can interact with arbitrary network services without centralized control (no, websockets don't work because they can't listen, webrtc does not work because it needs rendezvous servers). And neither can it access your own filesystem. It is quite locked down. In a way you get compute cycles, but you don't get access to the machine's full capabilities. And they could trivially forbid loading file:// URLs or disable features for those since few people use those anyway, that way you would lose persistence and would be dependent on something to even host your software.

throwanem 10y ago
I don't see where I made mention of any concept of freedom.
FeepingCreature 10y ago
webrtc works fine. Rendezvous servers are a minimal cost, they're not involved beyond the setup, and you can run your own fairly easily. I'd argue it works better than sockets, especially for gaming, since there's no need to mess around with NAT.
- the8472 10y ago
  It's about freedom to run your own software, it is not cost or "works fine". Webrtc has a dependency on and is controlled by a 3rd party. You can't talk to someone in the next room via webrtc without some party running the server and providing a service to you. If they decide to lock you out you can't use sockets anymore. With real sockets you can just send a multicast message to find all devices on the local network and talk to them directly.
  - Dylan16807 10y ago
    You can use any rendezvous server in the world. Even without free ones, you could buy access for $1 per decade. There is no third party in charge. There is just a requirement to use some party anywhere.
    - the8472 10y ago
      Imagine you're in china. Do you really want the basic ability for two devices to talk to each other depend on something that goes over the internet? And they still have to agree on the same server, that provides a certain lock-in or inertia. Ultimately it means you have less control over your network connections than with real sockets. And for the purpose of discussion this about the freedom of running software on your computer and webcontent not being equivalent in that regard. With webrtc signalling servers you're just kicking the ball down the road because then you need to be able to run a server with access to real sockets on some other machine, just to use those poor imitations of sockets.
      - FeepingCreature 10y ago
        > Do you really want the basic ability for two devices to talk to each other depend on something that goes over the internet? Set up your hosts file or edit the js to point at a local server. Of course, if you're in China you'd get in trouble making connections to an outside STUN server but if you're in China you're in trouble making connections to the outside anyways, and the STUN connection is probably the least of your worries. > just to use those poor imitations of sockets ... that work across NATs without issues, as opposed to real sockets... --- In any case, WebRTC doesn't strictly speaking need discovery servers at all. See http://blog.printf.net/articles/2013/05/17/webrtc-without-a-signaling-server/ http://blog.printf.net/articles/2013/05/17/webrtc-without-a-... It still uses STUN for public-ip discovery, but comments indicate that can be bypassed by just configuring the connection to use a local IP for STUN. Unsurprisingly, not many people seem to actually care about that.
        the8472 10y ago
        > that work across NATs without issues You say that as if stun didn't exist in the udp/tcp realm. bittorrent clients in fact engage in serverless stun by using mutually reachable peers. real sockets are strictly more powerful than webrtc, period. Also, that argument is becoming more and more obsolete as ipv6 adoption increases. And again, this is not about utility, it's about control and freedom. > In any case, WebRTC doesn't strictly speaking need discovery servers at all. Even if you don't use a server you need to exchange one-time connection tokens out of band. You can't re-establish connections at a later point either. And it does not support multicast either. So no, you can't just have devices talk to each other. Anyway, you're not even responding to my central argument. Web content is not a substitute for unfettered native access because you need native access to things (e.g. running a server) to even be able to run web content.

by the8472 10y ago

throwanem 10y ago

I don't see where I made mention of any concept of freedom.

FeepingCreature 10y ago

webrtc works fine. Rendezvous servers are a minimal cost, they're not involved beyond the setup, and you can run your own fairly easily. I'd argue it works better than sockets, especially for gaming, since there's no need to mess around with NAT.

the8472 10y ago
It's about freedom to run your own software, it is not cost or "works fine". Webrtc has a dependency on and is controlled by a 3rd party. You can't talk to someone in the next room via webrtc without some party running the server and providing a service to you. If they decide to lock you out you can't use sockets anymore. With real sockets you can just send a multicast message to find all devices on the local network and talk to them directly.
- Dylan16807 10y ago
  You can use any rendezvous server in the world. Even without free ones, you could buy access for $1 per decade. There is no third party in charge. There is just a requirement to use some party anywhere.
  - the8472 10y ago
    Imagine you're in china. Do you really want the basic ability for two devices to talk to each other depend on something that goes over the internet? And they still have to agree on the same server, that provides a certain lock-in or inertia. Ultimately it means you have less control over your network connections than with real sockets. And for the purpose of discussion this about the freedom of running software on your computer and webcontent not being equivalent in that regard. With webrtc signalling servers you're just kicking the ball down the road because then you need to be able to run a server with access to real sockets on some other machine, just to use those poor imitations of sockets.
    - FeepingCreature 10y ago
      > Do you really want the basic ability for two devices to talk to each other depend on something that goes over the internet? Set up your hosts file or edit the js to point at a local server. Of course, if you're in China you'd get in trouble making connections to an outside STUN server but if you're in China you're in trouble making connections to the outside anyways, and the STUN connection is probably the least of your worries. > just to use those poor imitations of sockets ... that work across NATs without issues, as opposed to real sockets... --- In any case, WebRTC doesn't strictly speaking need discovery servers at all. See http://blog.printf.net/articles/2013/05/17/webrtc-without-a-signaling-server/ http://blog.printf.net/articles/2013/05/17/webrtc-without-a-... It still uses STUN for public-ip discovery, but comments indicate that can be bypassed by just configuring the connection to use a local IP for STUN. Unsurprisingly, not many people seem to actually care about that.
      - the8472 10y ago
        > that work across NATs without issues You say that as if stun didn't exist in the udp/tcp realm. bittorrent clients in fact engage in serverless stun by using mutually reachable peers. real sockets are strictly more powerful than webrtc, period. Also, that argument is becoming more and more obsolete as ipv6 adoption increases. And again, this is not about utility, it's about control and freedom. > In any case, WebRTC doesn't strictly speaking need discovery servers at all. Even if you don't use a server you need to exchange one-time connection tokens out of band. You can't re-establish connections at a later point either. And it does not support multicast either. So no, you can't just have devices talk to each other. Anyway, you're not even responding to my central argument. Web content is not a substitute for unfettered native access because you need native access to things (e.g. running a server) to even be able to run web content.