Open sethkimmel3 opened 4 years ago
Subscribe only is a must.
For the authentication, I don't want it complicate the kraken code. It's recommended to make your own API server, and proxy all browser RPC calls with your own server, so that you can craft your own authentication logic. We use this method in our Mixin Messenger app.
Thanks for the reply @cedricfung.
I spent a good amount of time reading through the code to figure out how to implement such a method. It looks like one solution is to have the client run the publish method with no track added to their local RTCPeerConnection. The problem preventing this from currently working is that the peer is then recognized as having their track closed, and this throws an error after some time. If a peer could be created which is recognized as a listener-only whose cid is set to reflect that, then the connection could be kept open. I'm not sure if there is a more efficient way of doing this, but this is what I've come up with so far.
As for authentication, I understand you not wanting to insert complexity into the server. I have also written my own backend server to handle authentication, but it is complicated by the idea of introducing users who can only listen in. Are you able to actually call the kraken methods from your backend code and return them to the client? I thought this would not be possible since it receives data from the DOM itself. If it is possible, that would be awesome!
It's possible to proxy the RPC calls with your server. When you publish from the browser, instead of kraken, call your server API, and your server will do some authentication or other things then pass the call to kraken, then get the response from kraken and finally deliver the response to your browser. It's also possible to modify the kraken response before delivering to the browser.
Interesting! Are you doing that in node.js yourself, or are you using another language for your backend?
Any thoughts on the design I proposed to introduce a listen-only method?
I think your listen-only proposal is brilliant, add a param to allow publish without track, so that kraken will create a simple pc without any SDP and waiting for the subscribe.
So I think a better method may be improve the subscribe method, use some 'SUBSCRIBE-ONLY' cid and build a new peer from there. This doesn't change the publish method, because if publish without track then it seems misleading for people.
And I use Golang in most of our backend code, but language doesn't matter at all.
Thanks, @cedricfung! I like this plan too.
I'll work up a PR for this in the next couple of days. It may take a few iterations because I'm not very used to Golang (and this codebase in general), but I'm sure I can come close.
Sorry for the delay. I have tried to merge this and do some code refactor. But found it would make code too complicated. However I am still going to make progress on this, so leave this open.
I am using Kraken to build an application which requires some room participants to be listeners only (i.e. do not publish their audio to the room). I am trying to figure out the best way to go about this.
Happy to help on building this out and submitting a PR but quite frankly don't know where to start.