MixinNetwork / kraken

🐙 High performance WebRTC SFU implemented with pure Go.
Apache License 2.0
335 stars 49 forks source link

Creating a listen only method #6

Open sethkimmel3 opened 4 years ago

sethkimmel3 commented 4 years ago

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.

  1. Can the current subscribe method already handle this? Do I just need to reconfigure the client side javascript to handle this?
  2. Regardless of the first question, there is a security design question this brings up. If a user is in listen-only mode and joins via the same room ID as those using who are publishing their audio, a user could theoretically inject a publish method themselves via client side code. One clever workaround here could be to create two room ID's for each room - one that allows a user to subscribe and publish, and one that only allows the user to subscribe.

Happy to help on building this out and submitting a PR but quite frankly don't know where to start.

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

sethkimmel3 commented 4 years ago

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!

cedricfung commented 4 years ago

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.

sethkimmel3 commented 4 years ago

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?

cedricfung commented 4 years ago

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.

cedricfung commented 4 years ago

And I use Golang in most of our backend code, but language doesn't matter at all.

sethkimmel3 commented 4 years ago

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.

cedricfung commented 4 years ago

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.