Show HN: WebRTC signalling data using QR codes
github.com
github.com
https://www.youtube.com/watch?v=Gvsm84xL9Sk (https://github.com/phiresky/webrtc-remote-touch-pen-input)
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.
And by the way, cool idea to use the pen on the smartphone.
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.
http://www.freepatentsonline.com/20160021148.pdf
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.
Even though there is public domain tech from 2014 using it? (@nilknarf's).
I was under the impression when something is part of the public domain there can't be a patent claim on it.
https://patents.google.com/patent/US20160021148A1 (see the "grant" status line)
I think it should not have been granted there being prior art, but for it to be turned over, I think it would have to be challenged in court. That's my limited understanding as a non-US person without any experience with patents whatsoever.
I also now of this Android App that uses WebRTC Audio/Video without server (no Internet or DHCP needed): https://github.com/dakhnod/Meshenger
I made a submission, in case somebody likes to discuss the need for serverless WebRTC: https://news.ycombinator.com/item?id=18203495
(Disclaimer: I am not the author of the App, but I helped out a bit)
You require the devices to be on the same network for this to work right?
The App uses ipv6 link local addresses (fe80::.. + mac address). But it also tries to make use the received IPv6 network prefixes. Also, the last contact address is stored. These approaches improves the probability a bit to find the contacts in other networks.
As a side note, many mesh networks are emulating a layer 2 network. With this, everybody can build up their own decentralized telephone network.
Nice. I'm very interested in being able to connect devices in areas where there is no Internet and using a mobile router, like in the mountains or in a bus trip through deserted areas.
- https://github.com/libp2p/js-libp2p-webrtc-star
- https://github.com/libp2p/js-libp2p-websocket-star
That would be going back to using a server for the handshake.
In regards to using a DHT, that's something I have not researched. I am not sure how long an offer is valid, were you thinking of being able to update them as needed whenever you want to establish a connection?
Yes. I have toyed with js-libp2p to obtain "providers" based on a key, but I believe the part of js-libp2p that allows you to participate in the DHT isn't quite done [0]. I imagine you'd make a CID that would be a simple hash of some shared string. Then you'd tell the network you are a "provider" with that CID, and when requested, you give the offer (AES'd w/ shared string or other shared secret?). The client can just connect to the same DHT and give the hash and get the (encrypted?) offer. Not sure if IPFS has a way for me to prevent other people from serving/replicating the CID I am serving instead of forcing it to be a hash of the content. A similar approach can happen on BT mainline w/ an infohash maybe.
I did some research a year ago (https://aquigorka.net/post/how-to-find-peers-in-the-decentra...) and going back to it I found this repo that uses the DHT to connect peers: https://github.com/mafintosh/peer-network
The author is one of the main contributors to the Dat project so I'll do some catching up to see what they've come up with.
The challenge is that multiple peers could announce under the same hash on the DHT. Thus I have code to perform a handshake to verify peers upon connecting.
Another project worth mentioning is hyperswarm [3], also created by the Dat Project folks. It's planned to be their new method of connecting peers on a DHT in Beaker Browser.
[1] https://www.npmjs.com/package/swarm-peer-server
[2] https://github.com/samuelmaddock/metastream/blob/master/app/...
The flow is very similar to yours, down to the flashing QR codes! https://youtu.be/rw4f9LfqqpI?t=8
Did you continue to experiment with it? Improve the experience? Try out different approaches?
I lost interest in this approach because it was way more practical to give up on serverless in exchange for only scanning in one direction instead of both ways (e.g., scan a QR code once on mobile to both open the webpage and join a websocket channel, then use it to upgrade to a webrtc connection). It's a neat trick for use cases like AR.js where this is natural to do: https://github.com/jeromeetienne/AR.js
When I played around with WebRTC for the first time I used copy-and-paste signaling.
When I played with WebRTC, I was able to pack the relevant SDP data to just 80 bytes:
- 1 Type of the SDP - Offer or Answer
- 1 Packet size in bytes (not including ECC bytes)
- 4 IP address of the transmitting peer
- 2 Network port that will be used for the communication
- 32 SHA-256 fingerprint of the session data
- 40 ICE Credentials - 16 bytes username + 24 bytes password
Or, you could send the files over WebRTC datachannels after establishing the connection!
Edit: AFAICT, this isn't correct. Your browser has no notion of a "default" (or any other) STUN/TURN server. The JavaScript doing WebRTC has to specify one.
That said Google runs one, at stun.l.google.com:19302; but it isn't clear if that's something third-parties could or should make use of (or if Google even permits such activity), though it seems like plenty of examples (and perhaps even real-world uses) make use of it.