4 ms·

I love love love these kinds of experiments. Reminds me of the Early Web. I really wish WebRTC was easier to use. I wish there were some good faith free serve

I love love love these kinds of experiments. Reminds me of the Early Web. I really wish WebRTC was easier to use. I wish there were some good faith free servers to do the… crap I forget the acronyms… the STUN and TURN stuff and whatnot to negotiate the connections. Ie. Not a proxy, just an operator. Having one I could use freely and comfortably would trivialize a lot of neat projects, particularly fun little multiplayer games.

justaman 3y ago
If you asked me 30 years ago what I thought the web would be in 2023, I would have said something similar to this.
- Waterluvian 3y ago
  Same. The way people share memes and funny videos with their pals, I thought we’d all be sharing these kinds of things. looks around at HN Okay so maybe we still kind of are doing that.
- aaron695 3y ago
  [dead]
davidmnoll 3y ago
I recently learned you can do the candidate server exchange without those servers. There was an implementation which used [this](https://github.com/cjb/serverless-webrtc https://github.com/cjb/serverless-webrtc) as a backend and a QR code to do the transfer. I can't seem to find it now. However they were having issues with the QR code reaching its size limit, leading to the question of whether you could break the message into a series of qr codes. Pretty interesting stuff, I was considering taking a crack at it as part of a project I'm working on. Edit: [here](https://franklinta.com/2014/10/19/serverless-webrtc-using-qr-codes/)'s https://franklinta.com/2014/10/19/serverless-webrtc-using-qr... the blog post about it
- thdc 3y ago
  You would still need a STUN server, though there are many public ones out there. The main idea in removing the signaling server is to somehow transfer the session description between clients e.g. one client scans a qr code that encodes the session description of another or sending session description through some existing chat application and allowing a user to enter it manually instead of having your own server do the transfer over some mechanism. Also it may be possible to avoid the multiple qr code thing this blog is talking about (qr code per ice candidate) if you just wait for the ice gathering state to be complete then send the session description, though they are correct that the session description in its entirety will most likely exceed the qr code capacity (coincidentally they use LZ compression in an attempt to lower the length, similar to what I tried long ago though I ended up deciding it wasn't worth it).
joshspankit 3y ago
IPv6 is going to be awesome for this (we hope)

justaman 3y ago

If you asked me 30 years ago what I thought the web would be in 2023, I would have said something similar to this.

Waterluvian 3y ago
Same. The way people share memes and funny videos with their pals, I thought we’d all be sharing these kinds of things. looks around at HN Okay so maybe we still kind of are doing that.
aaron695 3y ago
[dead]

davidmnoll 3y ago

I recently learned you can do the candidate server exchange without those servers. There was an implementation which used [this](https://github.com/cjb/serverless-webrtc https://github.com/cjb/serverless-webrtc) as a backend and a QR code to do the transfer. I can't seem to find it now. However they were having issues with the QR code reaching its size limit, leading to the question of whether you could break the message into a series of qr codes. Pretty interesting stuff, I was considering taking a crack at it as part of a project I'm working on. Edit: [here](https://franklinta.com/2014/10/19/serverless-webrtc-using-qr-codes/)'s https://franklinta.com/2014/10/19/serverless-webrtc-using-qr... the blog post about it

thdc 3y ago
You would still need a STUN server, though there are many public ones out there. The main idea in removing the signaling server is to somehow transfer the session description between clients e.g. one client scans a qr code that encodes the session description of another or sending session description through some existing chat application and allowing a user to enter it manually instead of having your own server do the transfer over some mechanism. Also it may be possible to avoid the multiple qr code thing this blog is talking about (qr code per ice candidate) if you just wait for the ice gathering state to be complete then send the session description, though they are correct that the session description in its entirety will most likely exceed the qr code capacity (coincidentally they use LZ compression in an attempt to lower the length, similar to what I tried long ago though I ended up deciding it wasn't worth it).

joshspankit 3y ago

IPv6 is going to be awesome for this (we hope)