Similar project of mine that connects a phone to a PC browser using a WebRTC QR code so you can use a pen / touch on the phone to create drawings on the desktop:<p><a href="https://www.youtube.com/watch?v=Gvsm84xL9Sk" rel="nofollow">https://www.youtube.com/watch?v=Gvsm84xL9Sk</a>
(<a href="https://github.com/phiresky/webrtc-remote-touch-pen-input" rel="nofollow">https://github.com/phiresky/webrtc-remote-touch-pen-input</a>)<p>Sadly it needs a (tiny) server component to exchange the initial connection information - using a QR code in both directions is smart, but also pretty annoying for the user.
This is great, thanks for posting it. I've had the same idea myself and started and abandoned this exact same project a few times. Same down to cutting the SDP up into multiple QR codes. I am glad to see this brought to life.<p>I am also surprised to see @nilknarf has done that in 2014! (As per their comment.) Don't know how I didn't come across his post during my research into this, but checking it now, someone in the comments posted a link to a patent which captures this idea.<p><a href="http://www.freepatentsonline.com/20160021148.pdf" rel="nofollow">http://www.freepatentsonline.com/20160021148.pdf</a><p>The patent must be invalid, because it's from 2016 and there is clearly prior art, but it kind of sucks, because it basically means polishing something like e.g. @phiresky has done with the remote pen just means if you succeed in bringing down the time to connect and make it something usable enough for users, you're opening yourself up to a claim if you decide to package it up into an app.
Nice!<p>I also now of this Android App that uses WebRTC Audio/Video without server (no Internet or DHCP needed): <a href="https://github.com/dakhnod/Meshenger" rel="nofollow">https://github.com/dakhnod/Meshenger</a><p>I made a submission, in case somebody likes to discuss the need for serverless WebRTC:
<a href="https://news.ycombinator.com/item?id=18203495" rel="nofollow">https://news.ycombinator.com/item?id=18203495</a><p>(Disclaimer: I am not the author of the App, but I helped out a bit)
I've wondered about other signalling mechanisms. I figure you could use a DHT (js-ipfs/js-libp2p or webtorrent BT mainline) and put the offer directly on the DHT (AES'd?) or if it's too big to be a key, seed it as the stored value for its hash using those systems.
Cool. In case you are interested in a similar approach using signaling through audio (you might say an "audio QR code"): <a href="https://github.com/ggerganov/wave-share" rel="nofollow">https://github.com/ggerganov/wave-share</a>
Did you happen to see my post on this?
<a href="https://franklinta.com/2014/10/19/serverless-webrtc-using-qr-codes/" rel="nofollow">https://franklinta.com/2014/10/19/serverless-webrtc-using-qr...</a>
(The demo unfortunately doesn't work anymore since it's from 2014)<p>The flow is very similar to yours, down to the flashing QR codes!
<a href="https://youtu.be/rw4f9LfqqpI?t=8" rel="nofollow">https://youtu.be/rw4f9LfqqpI?t=8</a>
Doesn't work in Edge because createDataChannel isn't supported: <a href="https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#Browser_compatibility" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConn...</a>
Cool idea, however I could not get it to work with Chrome on a laptop as a host (with the moving qr codes) and a S5 phone (join) also running Chrome pointing at the laptop (it could see the qr codes on the transparent video). It didn't connect.
I am the author of the Android, iOS and web based Webrtc application and developed our own media and signaling servers (C++) and customized XMPP for chat.
Currently it is in private beta but I'll let you know soon.