Allow self hosted handshake server and provide the code of webrtc.js please

[derpeter]

At first let my thank you steve for the impressive software and making most of it opensource.

We are planning to use OBS.NINJA at this years virtual congress of the chaos computer club. (ccc.de rc3.world events.ccc.de media.ccc.de for more information). While we already installed a test instance of obs.ninja, as we on the one hand don't want to use your resources and on the other hand need to keep privacy of our users in mind, we realized that we can't configure the webrtc echo server. Sadly this means we either need to reverse / reimplement the webrtc.js and whats need to be done on server side or step away from obs ninja at all. This is on the one hand because of our own strong believes in privacy and self determination of personal data and on the other hand because of German and European data protection laws. Also we are not comfortable to serve a .js file to our users which they can't see the source of.

We are wondering what is the intention on keeping these two components closed and what we could do to convince you to opensource those too.

[steveseguin]

Hi @derpeter ,

Thank you for the post. I would love to support you and your conference; it sounds exciting.

I haven't really had time to consider where this project will go long term; sustainability is a concern. I'm also faced with professional conflicts of interest, as I am the CIO of Stage TEN, and so I've done what I feel helps me avoid potential conflicts there. The app is p2p based, so obfuscating some of that logic I feel also helps avoid potential abuse of those peer networks. Most everything creators need access to for customization as a production tool is available as open-source already.

What I think can work though, if privacy is the concern, is for me to work with someone who we both can trust and have a code review session together. The damage of open-sourcing every-file to the general public isn't something I'm prepared to do at the moment though. The way things are setup currently motivates me to keep working on OBS.Ninja, fast and hard, as I can worry about decisions later. If I can no longer can afford to work on OBSN, I can of course open-source it then as a parting gift.

[derpeter]

Hi steve, thanks for the very quick response!

Hi @derpeter ,

Thank you for the post. I would love to support you and your conference; it sounds exciting.

I haven't really had time to consider where this project will go long term; sustainability is a concern. I'm also faced with professional conflicts of interest, as I am the CIO of Stage TEN, and so I've done what I feel helps me avoid potential conflicts there.

This is of course unfortunate but also understandable. On the other hand it may be a very good advertisement for Stage TEN to official support opensource and privacy here. Maybe think of a dual licencing model if that supports your business case.

The app is p2p based, so obfuscating some of that logic I feel also helps avoid potential abuse of those peer networks.

I'm not a webdev so i might miss something here. What peer network are we talking about. So far i only see connections either between users or the turn server. Both would be not affected by open code. In fact they would benefit as potential issues could be discovered by the community.

Most everything creators need access to for customization as a production tool is available as open-source already.

What I think can work though, if privacy is the concern, is for me to work with someone who we both can trust and have a code review session together.

For the server part that would be an option, even if we very much would prefer not to go down this road. For the js we deliver to our users this is not an option as it is code executed on their machines and they need to be able to review that.

The damage of open-sourcing every-file to the general public isn't something I'm prepared to do at the moment though. The way things are setup currently motivates me to keep working on OBS.Ninja, fast and hard, as I can worry about decisions later. If I can no longer can afford to work on OBSN, I can of course open-source it then as a parting gift.

If by damage your mean a potential conflict of interests we probably can't do much to help here. If your fear for security implications we might be able to ask some excellent security experts to look at it without any costs for you.

[MyIgel]

Another thought to mention here would be that, if anyone has the intention to harm someone, it wouldn't be a great deal to deobfuscate the code (and after that tinker around with it). So open sourcing it saves them only some hours of debugging but also allows a great community to find bugs even faster and fix them before they can harm anyone.

[steveseguin]

There appears to be a lot of interest in this request, so I've started making an effort to address blockers for me here. I'll also be seeking help from advisors this week, hoping to decide on what strategy is best for me, rather than delaying that decision like I've been.

There are some big ideas I have to make OBS.Ninja even better, including native mobile apps, hardware-encoder support, larger mesh networks, and free managed services. Some of these ideas I think will be truly disruptive, so I'd want to ensure I can make those pathways possible.

I appreciate the offer with the security audit; I may take you up on that soon. If there are some individuals who have successfully navigated a dual-license strategy, I'd be keen to have a call with them to seek their advice. It seems very easy to do wrong.

Also, there are also some developer roles I could use help with; having committed time by even one or two truly exceptional developers would be a definite factor in me finding value and comfort in opening up more.

Thank you everyone for the feedback and interest. Stay tuned. steve@seguin.email

[laf0rge]

I'm a developer who has been involved with legal qeustions of open source software for the past 15+ years (gpl-violations.org among other things) and am quite familiar with AGPLv3 and license compliance. I'm not a web developer, and unfamiliar with the specific project.

I would be happy to provide my input in case there is an interest.

From what I have been told (and thay may be wrong, please correct me), this is an AGPLv3 licensed program of which not all parts are released as AGPLv3, not even as open source. If that is the case, it is - as far as it seems to me so far - a contradiction in terms. You cannot create a "work" consisting of some parts AGPLv3 and other parts under an AGPLv3-incompatible license. Releasing something like that basically says: "Here is that code, but no matter how you try to use it, it will be impossible to use it legally and you will always be in violation of the license terms". While that may be legal to do, it basically puts all users into a trap, as it looks like they can use the software while in reality they cannot.

So basically there are the following options:

• the software is not one "work" under copyright law, but multiple different "works". This only works (no pun intended), if those relevant parts are reasonably self-sufficient and can be used independently without each other
• all of the "work" is released under compatible licenses. If any part of it is AGPLv3, then all other parts must be AGPLv3 compatible!

[derpeter]

@steveseguin Thanks you for considering to opensource the code.

I may have another point to sweeten the opensource side for you. We are developing and using a video mixer called voctomix. It is in use by us and some other crews mostly focused on Lectures and conferences. I will not go in all details here where it differs from OBS but the main point that might be interesting for you is that it is implemented as client/server model. This means your have the mixer it self on a headless machine e.g. in the data center while the GUI can run somewhere else. In the past it was mostly focused on local sources like capture cards but with the next release we are planning to also support SRT as source and sink. I already did my first experiments with integrating WebRTC and would love to make OBS.Ninja tightly integrated. For me this is only an option if its opensource. So this could be a big step forward for both application. Voctomix has already been used to record 1000sends of hours of talks e.g. https://media.ccc.de/c/36c3 and most of the other recordings on meida.ccc.de.

Regarding the audit, you already seen the first people starting to look into it with the potential xss reported the other day. So give the community a chance to help and i"m sure more will come.

[derpeter]

Hello @steveseguin

I was informed that the communication with you form my side or people associated with the issue was not optimal. I apologize if i offended you or put you under pressure. This was never my intention. I can't speak for other people who communicated with you and have no knowledge of most of it.

At this point in time i don't see how this will work out until our event starts and i will focus on other tasks and maybe help with kevin.

Feel free to close the issue, thanks for the time you invested to answer and considering to opensource it. Mary Christmas, stay safe.

[loelkes]

Even if there doesn't seem to be solution to self-hosting the handshake server I would suggest that it is clearly written in the documentation that it's actually not fully self hosted. There's just a line defining the existence of a handshake server and not clearly stating the implications. This would have spared me quite some research time.

[steveseguin]

Thank you for the feedback @loelkes I've updated the main wiki site and the install file to reflect your request. https://github.com/steveseguin/obsninja/commit/85b336bafd9887630604fa42bab41aaf06cd2755

I've not forgotten about this issue; it is a daily top-of-mind issue for me. Thank you for your understanding and patience.

[loelkes]

Nice, thanks! From what I understand there are two points in this discussion: the obfuscated webrtc.js and the missing documentation about the handshake server. I understand the concerns from previous authors about shipping code that they can't read but for now I would like to focus on the second part.

After looking at the messages it seems to me that the handshake server is stupid in a sense that it only does does a bare minimum handshake and exchanges IDs between the clients. For me it would be a first step to self host this handshake server. Together with my own TURN server I now could have a setup where I have control, it does not use any of your resources and I know that data is only transmitted to my servers AFAIK.

Would it be possible to open the handshake server if there's not much logic inside?