serverless-webrtc
serverless-webrtc copied to clipboard
cjb
How to actually make it nice
Sending that text to my next door neighboor is just going to scare him out. I wonder what are the ways we could do this (beyond QR codes)
Open for ideas:
- encode them into a gif..?
- base emoji (too long)
- ..?
A simple server with a small DB might be a solution:
- Create offer
- Upload it + generate unique link
- pc1 sends link to friend
- pc2 opens link -> downloads offer -> pushes answer to server
- server pushes answer to pc1 client
- done
Ideas :
- Can be done using webSockets / pulling using an infinite loop / SSE
The original issue is about making the data format easier to transfer to your neighbour. Each user still needs to pick the method of transfer.
@RaedsLab's comment is about automating the transfer method, so that users don't need to do it. This is a very good goal. However, it's a fundamentally hard theoretical problem. If it was easy, the WebRTC designers would have just made this part of the WebRTC standard.
For example, one problem in the above comment is with "upload it" - where to? A centralised service? Is that going to run the whole world's "serverless-webrtc" instances? People trying to solve this issue should think very hard for a significant amount of time (and do plenty of research into what has already been tried), then write down your ideas in a structured way as a formal and concrete proposal. Most "simple" ideas that took 10 minutes to think up, have already been thought of before, and are not suitable.
@infinity0 It could be a simple PHP script and an SQLite DB where everyone can upload a version of it on their own.
This is not perfect but it could be a "hacked-up" solution.
For a totally decentralized solution, a QR code (or any form of data encoded on an image) is probably a better solution (even if it means more work for the end-user)
Build it yourself and experiment with it, then you will learn some things and be able to properly understand my previous comment. On the other hand, if you're suggesting that other people do this work for you, I am explaining why it won't work, and why you shouldn't wait in hope. If you don't believe me, then see the first sentence of this post again.
The technique described by @RaedsLab is how everyone already does WebRTC negotiation in production. However, it is not serverless or decentralized, which is the point of this project.
@cjb @infinity0 I'll link here when it is done. The idea is to have a "self-hosted" centralization.
WebRTC seems broken... I would imagine that once you have the OFFER, you "should" have everything you need to send the ANSWER to the offer creator. So a QR code on one end "should" work. But I can't seem to find how WebRTC would support that scenario without an intermediary.
