Table of Contents

Date

13 Dec 2016

Attendees

Actions items from previous meetings

• Peter Monks to communicate WG eligibility rules to WG chairs (as part of governance refinements comms)
• Peter Monks investigate alternative voting mechanisms and report back to the ESCo
• Peter Monks to coordinate development of a proposal around reporting requirements
  • Project reporting proposal is available here
  • Working Group reporting proposal in progress
• Maurizio Pillitu configure CI / CD of symphony-java-client against the ODP (highest priority target for his existing CI / CD work)
• Former user (Deleted): draft a quick page on WG "scope" and distribute to mailing list for group iteration
  
  • All: review the page and update as appropriate
• Peter Monks to schedule email vote for ratification of API WG
• Peter Monks to cancel meetings on Dec 20th and 27th
• Peter Monks to check with Gabriele Columbro and Maurizio Pillitu regarding the possibilities of enabling multi-party cross-pod chat in the Foundation pod
• Peter Monks to update wiki content (specifically thresholds for inactivity) based on today's conversation
• Former user (Deleted) to send email to community (dev mailing list?) regarding bulk presence API in symphony-java-client

Agenda

Meeting notes

• Quorum is achieved
• Unable to locate Jira server for this macro. It may be due to Application Link configuration.  discussion & vote:
  
  • Arnaud: background: this is an open source project on the client side, built on the IETF / W3C WebRTC standard (which is also open source).  We're adding a layer of encryption on top of WebRTC.  For scaling up to 20 participants in a video call, WebRTC needs an SFU ("Selective Forwarding Unit") in the cloud to optimise routing and bandwidth usage.  It's also the perfect architecture to do recording, rather than doing it on the client side.  In order to work properly, these SFUs need to decrypt packets and forward them, but in large organisations (especially banks), that's not appropriate.  The proposal here is to add an additional layer of client-side encryption and leverage the existing WebRTC stack.  We don't touch the SFU (the server side components), and on the client side we slightly modify the libwebrtc (the core of WebRTC) and then modify the API, starting with Chromium, in order to be able to on-the-fly inject the keys needed for this.  In the long run I'd like to make a PR to the libwebrtc code and also to Chromium in order to get the features available for any enterprise using Chromium.  Perhaps also Jitsi (our open source solution for the SFU), and obviously Mozilla Firefox.  The stars are aligned and the focus is on us to offer something new to the enterprise world and our main market (banks).
  • Lawrence: so this is fresh development of a module that's going to fit into what codebase?
  • Arnaud: libwebrtc is open source (for years now) and is integrated into Chromium, Firefox and other browsers, but it doesn't allow the JS code itself to inject keys within the code in order to use it for encryption.  That's what we want to change.  The code will be new, it will be part of libwebrtc and Chromium.
  • John: so it's a contribution back to those projects, right?
  • Arnaud: first phase it's for Symphony mainly (Minuet, mostly), and we don't really need the standard committees to approve this to deploy it, since we (Symphony LLC) control what we deploy.   From our bundled version of Chromium to the same version of Chromium it will work right away.  The interesting part of going back to the standards committee to merge this request (which we're doing at the same time) is because we don't want to maintain it in the long run - we want it to be part of the core codebase.
  • John: so this is a temporary home to get something into the Symphony wrapper, but down the road you'll get agreement to contribute it into the standard libraries.  At that time this contribution would be null & void.
  • Lawrence: have we looked at the other libraries to see what sort of licensing rules they follow?
  • Arnaud: there is no code behind PERC - it addresses more use cases than what we need at Symphony.  They're looking for implementations to keep that working group alive.  Mozilla is in the process of doing this, and we are in the process of doing this.  Once our project is done, it's a partial implementation of PERC.  In terms of licensing we have a match from day one for libwebrtc - I need to double check that for Chromium.
  • Lawrence: two thoughts I have from talking through this:
    1. Whether we might end up in a situation where the initial contribution conflicts or gets in the away of contributing it to those alternative codebases.
    2. Whether it makes sense to do this as a Foundation project if it's a short lived thing, or whether this is an unnecessary step or may add a layer of complication to it.  It seems like a new scenario and I'm trying to think about the ramifications of it.  I'm not sure what benefit we would get from doing this, in terms of furthering the Foundation's goal.
  • Arnaud: there's no guarantee the standards committees will merge our contribution.  And if we don't have an umbrella to help us to paint the big picture, with the whole FinTech industry behind us it's a powerful tool, I'd like to have that behind us.  libwebrtc has an open license, Chromium I'll check.  Here at Symphony we don't support Mozilla Firefox or other browsers, but in the long run we might want to add those.  So it's an opportunity for us to speak up in the W3C and IETF and get some visbility in what we do and our expertise around security for communication in banks.
  • Lawrence: if we approach the Chromium project and they say "we won't take this", there's nothing preventing us from open sourcing it via the Foundation, right?  It seems like kind of a funny order for something if the objective is to submit the code to these other projects.
  • Arnaud: we are already talking to the Chromium & libwebrtc team at Google, and it's an ongoing discussion.  We don't know yet if they'd be interested in this use case - that's an effort we need to make.  There's no guarantee they'll accept.  If  they don't, we'll need to gather a community around it to support it in the long run.
  • Lawrence: what's the time frame for knowing more about these conversations?
  • Arnaud: we could finish the project in 6 months.  We are targeting to demo a first version at the IETF in February, so it's going to be pretty fast,.  But we've been preparing this work for months, talking to the standards committees &their members for a while, so that's why the timeline is so short.
  • Lawrence: it seems there are two routes we can go down:
    1. try to make the contribs to the projects where you want the code to ultimately reside, then contrib to the Foundation if that doesn't work
    2. contrib to the Foundation then shut down those projects if they're successfully contributed to the upstream projects
    • I would wonder why not do the former, given it seems simpler
  • Peter: there are also 3rd party developers involved in this initiative - using open infrastructure may make this easier tactically
  • Arnaud: I want to host with the Foundation - I'm not just looking at this as a Symphony specific thing.  I want to look at this more globally.
  • James: I agree with Lawrence.  I can see you want somewhere to house it in the interim.  I can also agree that it seems the end goal of getting it into other project is a bit contradictory to getting it into the Foundation.  From the timeline in the JIRA in theory this is done mid 2017?
  • Arnaud: that's correct - that's the first effort.  Just on Chromium there are more than 200 commits per day - probably similar for libwebrtc.  The main effort isn't about changing the code itself - it's about changing the pipeline to build libwebrtc on one side, Chromium on the other, with our modifications, and that's a massive effort.  We don't know when the Chromium team will accept our patch.  If we need to maintain this it's a significant amount of work and we don't really know when it's going to end up.  So my timeline is about the main effort for the first version of this feature, but after six months there will obviously be maintenance especially waiting for the PR to be merged.  And if that's a no-go then it's going to be a significant project that will continue under the umbrella of the Foundation.
  • James: I don't have any objection outside of due diligence to make sure that by contributing it to the Foundation we don't preclude anything with the other projects.  I think that's the biggest risk.  If this is your preferred ordering and don't want to operate in limbo while you figure out if the contrib elsewhere will work or not, then I'm ok with that.
  • Mike: I can see both sides of it - I understand why Arnaud wants to do this, but I also think it's premature if the end goal is to get it into other projects.
  • John: does it impact distribution at all?
  • Mike: it can't
  • John: so I think you'd build it there, then maintain it as a delta in your own code base before it's accepted by the other groups?
  • Arnaud: we're not talking about just one group.  We're talking about libwebrtc (W3C) and also Chromium (Google).
  • Mike: we'd also have pull requests for both groups.  It's far more visible if it's open PRs in their repos.
  • Arnaud: but I also want to offer the standards guys and libwebrtc and Chromium teams visibility into the specs from the early days of the project.  It will be a common effort.  I also need the expertise of the Jitsi and Mozilla communities, as they're doing the same effort for Firefox.
  • Mike: I see value in putting it out there
  • Lawrence: I don't think you need a contrib to share information with these groups.  The nightmare scenario is that your work is Apache-licensed but that's incompatible with those other packages.  Because you don't own the copyright you can't relicense that underlying code.
  • Peter: that's a problem regardless of where the code is hosted though.
  • Mike: Peter what's your thought from a Foundation perspective?
  • Peter: licensing is checked by the Foundation anyway, regardless of the outcome of the ESCo vote (it's something we're pretty serious about).  I also see some benefits for Arnaud and team, such as "marketing visibility" with these other groups - being able to say they're a legitimate open source initiative in a substantial industry (banking).
  • Mike: it can also be a place where folks can pull down a fully working package.
  • Lawrence biggest concern is backing ourselves into a corner, but it sounds like we're not going to do that.  Has this been LLC-internally approved?
  • Arnaud: yes
  • Mike: I think I'm ready to vote!
  • Peter: objections to a vote?
    • <none>
  • VOTE: to approve  Unable to locate Jira server for this macro. It may be due to Application Link configuration.

    • Former user (Deleted): +1

    • john.stecher@barclays.com: 0, because I believe this is better handled by approaching the other two groups.  But I'm not opposed to it going into the Foundation.

    • Lawrence Miller (Deactivated): +1

    • Michael Harmon: +1

    • Former user (Deleted): 0 (not present)
    • RESULT:
      • +1:    3
      • 0:      2
      • -1:     0
      • The motion is passed.
• API WG:
  • Peter: the vote passed and the group is having a kickoff meeting this Thursday Dec 15th.  Please socialise this with your teams as appropriate!
• WG Scopes:
  • James: it's a one-liner so I'm not sure it deserves a wiki page.  I'll email it to Peter to put into the next agenda.
• Feedback on bot-sym-browser
  
  • Peter: background - we received feedback late last week on this project from some Apache guy (text reproduced above, in agenda).  We sent the feedback on to the project maintainer (Ryan D'Souza) who has since updated the readme to clarify that there are legitimate use cases for this bot.  So I think we're good for this specific case.  What i wanted to discuss was whether there was any general steering the group would like to do for similar cases in the future?
  • Mike: I think the guy took himself too seriously 
  • Lawrence: and the process worked
  • John: it's a bit like high class trolling  
  • Peter: FWIW I liked the light heartedness of the project's readme, and didn't see a problem with it per se.
  • Lawrence: me too - and I think the process of providing feedback to the maintainer, and letting them make a call is correct.
  • James: while there are limits to what we want to accept, this didn't violate what those might be.
  • Peter: and normally a project's readme (if one exists) would be reviewed by ESCo during approvals anyway, so I think we would have caught any undesirable content via the existing processes.
• AOB:
  • Reminder that we will not be meeting for the next two weeks - next meeting is on the 3rd January!  Happy holidays!

Action items

• Former user (Deleted) to send one-liner on "WG scopes" to Peter Monks for addition to the next agenda