Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: WebRTC signalling data using QR codes

github.com

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Show HN: WebRTC signalling data using QR codes

#41

Post by TomasHubelbauer »

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.

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.

Re: Show HN: WebRTC signalling data using QR codes

#42

Post by AquiGorka »

TomasHubelbauer wrote: post #41

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

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

Re: Show HN: WebRTC signalling data using QR codes

#43

Post by AquiGorka »

nilknarf wrote: post #37

Did you happen to see my post on this? https://franklinta.com/2014/10/19/serverless-webrtc-using-qr... (The demo unfortunately doesn't work anymore since it's from 2014) The flow is very similar to yours, down to the flashing QR codes! https://youtu.be/rw4f9LfqqpI?t=8

Hey there, I wasn't aware you had worked on the same thing (and 4 years ago!). Amazing, my hat is off for you.

Did you continue to experiment with it? Improve the experience? Try out different approaches?

Re: Show HN: WebRTC signalling data using QR codes

#44

Post by AquiGorka »

kodablah wrote: post #31
AquiGorka wrote: post #30

Earlier quoted context omitted.

Thank you for sharing, will keep an eye out for that thread. 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.

Although it uses Tor and is probably outdated, here is a PoC I wrote of bootstrapping a DHT network on the server side and using the client side to discover peers: https://github.com/cretz/tor-dht-poc

I saw you use IPFS in there, are you sure it did not use one of their signalling servers to find the peers?

Re: Show HN: WebRTC signalling data using QR codes

#45

Post by AquiGorka »

n-gauge wrote: post #33

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'm sorry to hear you could not get it to work, this means I have to improve the flow. I tested this using Chrome and both Android and iOS devices (chrome and safari). The catch is that you gotta point the series of qr codes towards the center of the camera.

Re: Show HN: WebRTC signalling data using QR codes

#47

Post by AquiGorka »

garlicfish wrote: post #35
AquiGorka wrote: post #28

Earlier quoted context omitted.

> Contacts are found by taking the devices own IPv6 addresses and replacing the devices own MAC address by the contacts MAC address. You require the devices to be on the same network for this to work right?

Yes, that is (mostly) true. 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 telep…

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

Re: Show HN: WebRTC signalling data using QR codes

#48

Post by TomasHubelbauer »

AquiGorka wrote: post #42
TomasHubelbauer wrote: post #41

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

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

I think this patent has been mistakenly granted this year:

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.

Re: Show HN: WebRTC signalling data using QR codes

#49

Post by AquiGorka »

TomasHubelbauer wrote: post #48
AquiGorka wrote: post #42

Earlier quoted context omitted.

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

I think this patent has been mistakenly granted this year: 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.

Oh wow, I am shocked to see the patent was granted and I'm very interested in understanding the repercussions. These might be big.

Re: Show HN: WebRTC signalling data using QR codes

#50

Post by nilknarf »

AquiGorka wrote: post #43
nilknarf wrote: post #37

Did you happen to see my post on this? https://franklinta.com/2014/10/19/serverless-webrtc-using-qr... (The demo unfortunately doesn't work anymore since it's from 2014) The flow is very similar to yours, down to the flashing QR codes! https://youtu.be/rw4f9LfqqpI?t=8

Hey there, I wasn't aware you had worked on the same thing (and 4 years ago!). Amazing, my hat is off for you. Did you continue to experiment with it? Improve the experience? Try out different approaches?

There were a few interesting ideas by others in the original comment thread. Mostly on how to compress the sdp so you can get away with just one large QR code without flashing (for example by presharing a dictionary or stripping the sdp down to the bare minimum: https://webrtchacks.com/the-minimum-viable-sdp/).

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

Post reply on HN