 on that brings us to quorum at this point so we can get started. I've started the recording and Chris with that I'll kick it over to you. Okay, thanks Todd. So just a sort of agenda review. We have a readout from the hackathon and the hackfest and I'll invite anybody who is present to weigh in on either of those after I get my sort of two cents and Todd I'd love to hear you know your perspective as well you were there for both and I know and then we've got the hyperledger release taxonomy I tweaked it a little bit I think you know it's basically done I know I was gonna talk you know I was gonna do some thinking about sort of her you know periodic snapshot releases but I think we should just sort of put this to bed and if we get to the point where we're starting to roll on wanting to do those kinds of things we can talk about what they look like and how they work and update it so I'd like to just sort of put that behind us and take a quick vote the wiki I guess Todd are you gonna update us on that yeah we can have a quick chat there okay and then Brian's not around so I don't know if you want to talk any more length about discussion yep we can and so forth then we've got a proposal from Takiyama son and he's going to go through the Eroha project he did this for us at the Hackfest and that was it was an interesting proposal and so he's gonna present it here and then we can have a discussion about bringing in as an incubator Satish is gonna give us a demo of the Java chain code that is now sort of ready for prime time and then we'll have workgroup updates and in addition to the workgroup updates I just wanted to Todd you did list them out but there's actually been a request and I don't see a reason why we wouldn't just go ahead and do this the folks that are working on sort of the the fabric SDK projects the Java node and and Python have been collaborating on a document and they've asked can they have a workgroup and so I think so and so we'll cover that when we get down to the workgroup updates so unless there's any other topics I think we can get going so Chris before you go I have one other topic and it's okay if we don't get to it today it's not urgent but I just wanted to bring it up to everybody's attention there was a comment made actually on the code of conduct it's being looked at by other projects in the Linux Foundation and so to be reused and there's an issue with the way we have defined the incident procedure so I would like to discuss this briefly yeah we'll put that and then certainly we can add it to the to next week yeah I'll be fine too thanks okay so very quickly then any any other any other okay I had proposed and I actually also sent you and Brian this oh the hip numbering scheme okay yes let's let's add that thank you okay anything else if not let's start with the hackfest and hackathon readout so this past weekend in Amsterdam we had two events one was a true hackathon you know with prizes and competing teams and a race you know over 36 hours to produce running code built on one of the hyper ledger projects and I and then the other was of course the hackfest which is our sort of every other month get together and you know combination of you know help new people on board as well as you know go through some of the some of the architectural issues and and have you know deeper and and you know better conversations that we're able to achieve on slack and so forth and I think that was that was also good so let's start with the hackathon so and I apologize for the background noise and people here hopefully the background noise isn't you know yep the the final touch is put on my new windows it's noisy and just in the nick of time too so so we had from the hackathon perspective there were I believe 20 teams in total I think there were 24 teams that registered and we ended up having to a couple where people either didn't make it and so didn't have a full team and so we had some combinations and so we had a total of 20 teams and I think it was 120 some odd individuals collaborating together so there were teams of five or six and and then we had what Todd about probably a dozen or so genius people people you know the genius bar right of you know people who are familiar with the technology and could answer basic questions whether on you know the fabric or sawtooth lake and or you know Linux and just how to get set up and so forth and and then we had obviously judges and so Brian and myself and John Clippen from MIT and then we had some executives from maybe an Amro all sort of you know peering over the shoulders of the teams as they were going through and getting periodic updates and so forth and it was really quite an event so 36 hours people slept you know up to the tables overnight some of them and it was really it was really quite an event I was really really pleased with you know just to turn out I certainly didn't expect you know that many people to be perfectly honest that it was a very well attended event the teams were really excited you know there was teams from AB and Amro from Accenture a few startups had you know brought teams together and then like I said there was some teams that were comprised of you know smaller sub teams if you will or cannibalized teams from startups as well as from larger companies and there were some IBM teams and this was a it was you know personally I got a lot out of it I learned a lot I learned about you know the fact that you know there's people that actually understand the technology how to use it and we're you know sort of really doing I think a very effective job of you know applying the technology to solution of a problem we had applications ranging from there was a voting you know a mobile app that you know you could use to do voting and delegation of your vote that utilized a blockchain on the back back end to trace both the results of the and the balloting you know and then you know making sure that they couldn't be changed as well as tracking who actually had the you know had the voting chip if you will if they were delegating a vote I thought that was really kind of cool that was my personal favorite there was a health care application sort of putting together a if you will a bank you know account for your health care information so this is sort of taking the EHR concept the electronic health record but putting it on the blockchain and putting you in control of the information as opposed to you know having it up in somebody's cloud I thought that was and that actually one that was the the number one prize winner that was actually a very very good application I think you know there's some privacy things and confidentiality that still have to be solved but it was it was actually pretty good there was a insurance for for for when your flight is delayed apparently in Europe there's a law that says that the airline companies has to pay if they're if they're late and there's like a $50 fine that they goes to the to the traveler but you have to get an insurance policy and so they actually sort of disintermediated the whole process and they just put it all on the blockchain and so the airlines would sort of pay up immediately so if flight was delayed you got 50 bucks credit on your on your cell phone kind of a neat application there was a you know then there were some typical fintech kind of applications of currency transfer there was a swift like application of doing funds transfers you know around the globe between banks there was another one that sort of was like a PayPal if you will where you go to the vendor and you buy something and then you basically do a transfer of funds between the banks shows up directly in the in the in the providers bank account was kind of neat you know so there's a number of different applications all of them interesting and and each of them sort of took you know at parts of the the total solution and you know really understood how it all fit together how the chain code worked and how the role-based access control stuff worked and so forth and the events it was really really pretty compelling not just you know simple hello world kind of things and you know then there was prizes there was a steel drum bands you know free free food and beer and coffee plenty of coffee to keep people awake it was I thought it was a really fantastic event I was really energized by it you know because people got you know the software was working I was like yay there was a couple little hiccups early on but we got past that and people were up and running and you know some of people were using clouds some people were you know running it locally depending on you know sort of what type of aspect of their project they were working on but it was for me I don't know I got a lot out of anotide I don't know what you guys thought of it yeah I'll be brief you know it was a really great experience going from Cybus the week before which had so much business focus so much focus in the finance sector going into a weekend hackathon where it was very grassroots community driven with people writing a wide range of applications on top of hyper ledger so exciting to see the ecosystem developing there and then moving into the more traditional hackfest with our you know core developers so it was a nice well-rounded two weeks and very interesting to connect with different segments of our ecosystem and community and really seeing that continue to thrive yeah I know yeah I don't have really much to add I thought that the hackfest was interesting I was also surprised by the turnout I only attended the part of the second day but I saw kind of the outcome and and did some networking with the people I was also impressed by the amount of excitement that the participant exhibited and they did have stories of sleeping in on a beanbag for a couple of hours over the last two days which really showed the level of commitment they also had so I thought it was great and it was also we saw some of them come to the tour our meeting afterwards which I thought was also a good way to get more people into the hyper ledger project community yeah and one thing I took away from the hackathon Todd and I've been sort of chatting behind the scenes with the guy that actually put it together but you know we have the starter kid in the fabric and and you know I know Dan and Nick you guys have you know sort of a similar kind of a thing but I thought useful if we could sort of take the idea of sort of a hack hackathon in a you know in a box kind of a thing where we could you know have an up-to-date and collaborative environment that got people up and running quickly that you know install all the right software provided them with you know enough of a sample that you know you could you know more than a low-world kind of a thing to sort of really sort of kickstart you know people in developing their solutions and if we could have something like that that we manage then Greg and team you know can sort of trace the and track the various hackathons that people want to pull together and we can provide them with a you know a kid this doesn't have to be hyper later hackathon could be just a blockchain one where we you know encourage you know people to start playing with the hyper ledger you know whether it's fabric or sawtooth lake or anything else and and and we're sort of making it as easy as possible for people to get up and running to be to be able to develop software I don't know what people think of that but I'd be you know if I can if I can get Tim to sort of contribute his stuff that's a good start we have the starter kit and fabric and like said I I know that Mick and Dan have something for sawtooth as well so maybe we could take those things and just sort of formalize it a little bit of a hackathon package I'm not hearing disagreement and I'm not hearing anything so sorry I think I was muted sounds like a good idea I think the other thing I was going to suggest that that's along those lines is you know we've talked about having you know like a public test network up in several cases as well it might be nice to have a place where we could showcase the best of those applications that we find as well that's actually a cool idea so one other thing I would add I mean the fact that the event was in Europe was interesting I mean it did the force a lot of people to to travel but it really showed to me at least and I think to everybody really that there is a vibrant community of people interested in this in Europe as well as other parts of the world and it shows that it is definitely worthwhile having these kind of events elsewhere than in North America yeah I agree with that okay and then of course we had the hackfest you know Monday and Tuesday and yesterday was a travel day for a lot of people and I thought you know again it was it was it was so it was two two good things I think came out of it there were some of the same people but because it was in Europe there was also some missing participants but we had new participants so we still had about 60 people I think right Todd certainly more than 50 yep yep tables were pretty much full and but we had a lot of new blood which was interesting you know we had people from Swift and Accenture and CLS and a few others Santander was represented there so there's a number of you know sort of new new faces and you know people were you know sort of a combination of sort of getting up and running and and and and using the software but also wanting to to get involved in collaborating and helping to build it and so and plus we you know Dan and Nick we had some you know some new sawtooth people from Europe that was that was that was nice so you know I think you know to Arnaud's point I think it was actually a very valuable thing and you know maybe I know Brian is interested in having a hackfest in in China and we probably would have a hackathon as well to sort of to make it you know if we especially if we can get people to sort of go from one to the next the way that that they did in Europe I think that would be a positive thing and you know I really strongly encourage those of you who couldn't make it you know because of you know travel considerations and so forth maybe we'll try and provide a little bit more you know of a runtime although we did have like two three months for this but I would strongly encourage people to try and make an effort to you know whether we go to I mean China I know it's a long way 13 hours for me you know maybe even more for some so but I do think that you know it would be a very valuable experience generally and so again I know Brian next time you know we get together next week I think he wants to talk about some of that we are taught in terms of you know sort of ongoing planning I think we're starting to think about something for New York where does that stay yeah so Brian kicked off a thread for that a day or two ago one of the thoughts was that there's going to be a member face-to-face December 7th and 8th in New York so the thought was potentially doing a hack fest the Monday Tuesday before that would be December 5th and 6th likely in New York just if folks are traveling traveling in for that and just you know given the concentration of member companies and technical community in that general area so you know I know a few people responded on that thread with a variety of feedback but definitely interested from those on this call is that something that would be valuable for people to do in December does New York seem to be a good location or is that challenging with travel budgets toward the end of the year whatnot but you know interested in the feedback from those on this call so Richard is so I think I also sort of suggestion of I think Raleigh or somewhere in North Carolina of the two of New York would be much better for us and just a little bit of feedback on Amsterdam and James Carlisle our chief engineer was there on Monday and Tuesday and I thought it was a fantastic event we actually presented to our or our three architectural working group on on our on James's trip report really collaborative but not you know but not overly differential there was some really hard hitting architectural discussions there and and good technical debate and he came back very very energized so so so good job great good to hear this is Jeremy server I there is an IBM sponsored hackathon for blockchain from their plumex team this weekend in New York that's right that I and others will be participating in but I would imagine it's probably safe to assume that can always travel and so just assume they have to have something and they continue to be important just have them in different places on a regular basis mm-hmm yeah we've been trying to move them around and like I said I know Brian's gonna want to talk next week about the potential for having a hackfest and potentially a hackathon you know sort of back-to-back the way we did in Amsterdam in China and so we'll have a discussion around that I think the New York thing again we have the members meeting I don't know if there was money with that but basically you know we've put out a call to all of the members of the hyper hyper ledger project you know all the sponsoring members some of them paid some of them not and so there's I think Todd this is still two or is it three or yeah well two per company will be joining right so two per company I think it's intended to be much more of a business thing but I thought you know some of us are gonna have to do double duty I know there's a board meeting for instance and so Dan and I'll be involved in the board meeting but then you know if we could have sort of another back-to-back kind of a thing where we had a hackfest or you know just a face-to-face meeting of the the technical community and then followed by the the members meeting itself that there's an opportunity to sort of commingle and maybe have a you know an evening event you know between them that kind of a thing and get a little bit of socialization but I think that would be a good it certainly from my perspective I'm keen on on doing it because I think we'll you know we won't have one in November and so it'll be a good you know two plus months stretch between now and then and I think it'd be worthwhile to sort of get everybody caught up again and and sort of back on track before the holidays so from my perspective I think it's a great idea cool just quickly before we move on because I know we've got a lot of other things Dan Mick would that work for Intel sawtooth lake team and Greg for you how does travel look for that Dan is Dan with the the members meeting and the board meeting on the one hand it would be convenient for me to since I already be out in New York on the other hand that's probably consuming the entirety of the the week on meetings activities so I'm kind of inclined against it but I don't really have strong feelings either way and on my side I can I can probably make the travel for at least a portion of the week all right Greg Hart I don't know we've heard from either of you but interested in your feedback for sure yeah you know I don't think I have anything you're sorry Greg go ahead you go ahead Hart sorry I'm no worries I don't think I have anything that week so yeah I'd be happy to to make it out there and and work with everybody I assume that the proposed date still the December 5th or 6th or whatever it was an email and so I think I could make that okay we'll have a look we'll definitely if other people have feedback shoot a note on the email thread we'll have a look at space and whatnot and come back to this group before we move forward with anything just to check next week as well yeah and and again closing the date early makes life much easier yeah yeah I agree and I think you know we I think as you know we should also try and make part of that be TSC meeting since the TSC will be sort of overlapping with the member meeting and so some of us won't be able to do both so I think we probably move the TSC meeting itself to to one of those two days and I think it'd be good to get together for that so that's another good reason okay so let's let's sort of move on so very quickly I think you know so we had this taxonomy proposal we were up to version 3 I just tweaked it to make it version 4 I think we had sort of and doing the release for the Hyperledger fabric 06 we concluded that dash developer dash preview was way too many things to type but we abbreviated that to preview but aside from that you know one of the things that I had sort of taken a to do was to sort of think about and integrate some thoughts on how to perform a snapshot release and so but I'm gonna leave that out for now because I just like to get this finalized and off the action item review until we get to the point where we're actually mature enough where we can produce one of those and then we can think about what it actually entails and so forth we do have in there the snapshot for you know when you build it locally and and having having that you know would be appropriate Shah appended and so forth so you can you know so you know exactly you know from whence the software was derived so I think we have it pretty much done I like I said I didn't really change anything except for the the the suffer developer preview and so I'd like to sort of put it to a vote to see if we can just sort of approve this and have it into the wiki which we'll talk about in a second once that's that's formally so Todd you want to and again people that maybe Todd put the link in so again everybody can see it but we've been through this a number of times and I think we're sort of at the place where we might as well just approve it before you know the other change I'm sorry the other change I made was I called this guidelines because again I know that you know we currently you know I don't think the intention would be that we were sort of enforcing any kind of rigid scheme but this is what we were recommending for people to use and so I also added the the title that it's guidelines cool any any questions or comments from anyone before we do a quick vote here so one quick question this is ono how does that compare with the tool that is being under discussion for versioning with go that's not so much a tool as much as the way that you do versioning and go is still rather immature and we're trying to find a way so that when you do a go get to download you know the package or whether you do a vendor the package that you're getting the appropriate version and the various schemes that are out there are you know either you have to put a specific version tag on things and you have to you know put them actually in physically separate repositories or you have to come up with some scheme that's going to pull a branch and so forth none of the tools are really very good so and the short answer or no is they're really you know at the best we can do today I think we'll be at the very high level so the sort of the minor release would be the best granularity we could get and then everything else would be the most current of those and so if you're following this ember you know policy correctly then there should be no breaking changes when you're doing a minor release and so therefore and certainly there shouldn't be breaking changes when you're doing a you know a bug fix patch and so forth so I think that that will work but again I think it's going to be I think we'll learn over time but I don't think it should change necessarily how we you know how we remember these things I mean in any event we still want to be sort of telegraphing through the version whether it's in change or not and you know if it's a fix pack what version is it all right that's good thank you I just want to me I was wondering if there was some incompatibility already knew about but so no not really no it pretty much fits but like I said you did you cannot I'm not aware of any way that you can get the granularity that we're looking for all the way down to the you know I understand flow thanks this is Jeremy from an adoption of you what you did was use the go path to be the latest stable release automatically by default treated as a distribution mechanism as opposed to develop a package method when we get to the point where we have stable ones that might make sense Jeremy I think and in fact it does make sense to have the sort of the naked pole work that way when we're in turn the way we are now with certainly with the fabric it doesn't work that well because if you're just doing development and you want to be working on a stable version that's fine but if you're you know if you're actually working on the platform itself and trying to develop it it makes it a little bit more difficult right you have to you have to go through and you can't use the typical go tools you have to sort of fake it out by cloning the repository checking out a branch and so forth it's a little bit clunky all right so any other questions or shall we vote at this point I say go for it all right it looks like a plus one from our know Chris yes Dan yes Greg yes part yes Mick yeah Morali yes Richard yes all right so that passes unanimously cool thank you guys next up very quickly because we're yeah five minutes the wiki what's the plans for the wiki I think the the check at this point was were there any showstoppers from the technical community or any hesitations to migrating over to the docu wiki at wiki hyperledger.org or if people feel comfortable at this point to move forward with that in terms of starting to transition you know I can help with some of that and obviously the community will help as well I think really the only thing holding things up at this point was any hesitations that people had or anything else that they wanted to see get ironed out before we start with the migration. One question that came up yesterday in the white paper group was just who will be responsible for doing the migration is your expectation that each of the owners of the documents pick them up and move them over or is there going to be an automated process? Yeah I think it's going to be more of a manual process so I can obviously help with a lot of the TSC focused stuff but then the individual work groups and whatnot the expectation would be that they would migrate their own stuff over it's good sorry some documents have been migrated already obviously who did the dub. I don't know I know that this guy Georg had done a very good job of exploring it and researching it and you know had a number of plug-in recommendations to make things a little bit easier to work with and so forth but I think for the most part my understanding is that it should just be able to cut and paste the raw markdown and a little minor cleanup so I mean it's a piece of work and Todd's obviously going to help us with the TSC section but maybe we could maybe we can all sort of pitch in I'm happy to help with a few pages I don't know. This is Greg I might only comment was that well first of all I think the lack of a wiki is really hurting us so I don't want to say anything. I agree. But that said I remember there was some conversation about options or plugins or whatever that would help with the markdown import is that already in place because I haven't followed this last few weeks like do we have the ability to just take the markdown and import it now or is that something we still have to translate to the to the docu wiki format? I'm not sure on that one Chris I don't know if you've seen any more and I haven't heard back from the LFIT notes so I can ping them. Yeah Gayark is on the on the call I just saw him paste something in where he's done some test migration I know Gayark I don't know if you're on the voice or not it'd be you know if you have any input that'd be great but I think Todd you said you were gonna check with the team and you say you hadn't heard back with them. Yeah so let me send a note right now. Okay so obviously we need to get the plugins that works for you. Okay go ahead Gayark go ahead. So what I basically did is looked at the moving several pages it takes a few minutes for each page since we don't have the markdown plugin at the moment and what I just do is replace the things that you can see on the test migration and I use some regex commands to do that fairly quickly. I don't think it's too much of a hassle it just is copying manually takes a while. So I guess the question is is the plug-in something that we can easily just have someone install or is it a big deal? And that's what Todd was checking with the team that supports the service. He just hasn't heard back from them. Yeah if I may it is not a big deal I can't do it but it should be relatively this should be like a one-day thing to knock out. Well if that's the case that would be my preference but otherwise I think Gayark's solution is in the interest of expediting the process let's just get something in place. Yeah so Todd let's see if we can't sort of put a little bit of pressure on the IT team. Yeah I've just sent a note. And I can get a decision either one way or the other and I guess then the other question was are we gonna reboot and sort of you know clear everything out or are we gonna leave it the way it is and my preference would be let's just leave it there's no harm in anything that was put out there I don't believe and then that way people have already started to try and test out a migration of something that they won't have to do it again. You mean cleaning up the new content? I thought you were talking about cleaning up the old content. Once we've migrated everything do we delete the old stuff is my question. Oh no no no I think the question was that some of the thinking had been that we've left this thing open as a playground to sort of toy around and play with things and that we would then nuke it and do it again and I don't see a reason to nuke it is what I'm saying. In terms of the old stuff yes I think we want to actually lock that down and so that would mean Rai would put the last turn of the screw and it would probably make the wiki disappear. Sounds good to me. I think that's a good idea because it's not because it doesn't look like there's a whole lot of trash for it and it looks like people put some stuff with it. That's right and we can always delete the you know individual things that don't seem appropriate or relevant. I would hate losing the work that Georg has put in. No I agree. I do want to thank you. Yes that was a bit of work. We just need to update those pages and then we should be good to go. Mic reading all the other pages. Again I think for the whole team Georg thank you very much. Yes. Yes you're welcome. Another feature that the doka wiki has that we couldn't have with the GitHub wiki is categories. So when you go to the sitemap page you see that I created some groups to group the pages under and maybe we can come up with a way of categorizing our pages and using that when we create new pages to keep the wiki clean. All right so Todd why don't you follow up and see if we can't get those plugins plugged and and then whether or not we should probably look at maybe Monday being let's just sort of start pulling stuff over. Cool sounds good. Okay thanks. Alright next up is I'm gonna where's my thing. I'm sorry. I'm gonna put you on next week if you don't mind I'd like to get to Taki Emerson's proposal for a Roja. No problem. So Todd let's put that on the agenda for next week. Yep sounds good. So for Roja you are? I see him. Yeah I just changed him to presenter. Makoto are you there? Yes I'm here. All right looks like it's working now. Okay great. So yeah where should I start? So I explained this in Amsterdam. I spent actually quite a lot of time as people had lots of questions. And I'll bring up the proposal here. Here we go. Can everyone see this? Okay so I assume everyone has seen the page. So our proposal in short is his new project for incubation that we're proposing with the three different co-sponsors Hitachi entity data and Kogu who are also hyperledger members. The basic story is that we want to create a set of blockchain C++ components that together can form its own ledger that stands alone but also these components we want to be callable from projects such as Fabric and Satut Lake. And the main reasoning behind using C++ or one of the main reasons is up until now there hasn't been any development environment for C++ developers to contribute to hyperledger and there's quite a lot of C++ developers in the world. So we want to create an environment where people could create C++ components. Also C++ is a very dynamic language. C++ 17 is out next year and it seems to be getting better and better as a language over time. So it's much better than you know 10 years ago. Also one other feature of our proposal are three different libraries for interface for mobile and web application development. So until now hyperledger as a project hasn't really had much support for user interfaces or user experience. So we want to make it easy to create native iOS and Android apps as well as make web apps. So we have a Swift iOS library, an Android library, and a JavaScript library that are all part of the submission. So the goal I'll just briefly showcase one of these. Let's see here. Okay, here's the iOS library. So we have a Cocoapod install file so you can just install using pod install. If you're iOS developer you probably have seen this before. And then once you install the library you can just import it. So for example import it to how Swift. You can create a key pair just like this and then you can do different things with keys, get account info, etc. So basically it's really really easy to build applications. So for example if you're in a hackathon or something it's very useful to have libraries that can quickly do a basic functionality like this. Now as far as our proposal, so the first version here is made for Iroha but really you know we got lots of feedback at Cybos and in Amsterdam and we don't want to stop it there. We want to actually make it not a Iroha iOS library for example but a Hyperledger iOS library. So for example kind of abstract out differences between the different ledgers in the project and just have a basic concept such as creating key pairs and doing membership registration. As much as possible just be able to create an abstract interface for people to do. It doesn't matter what kind of back end they're doing this. So that's the end goal or the vision of what we want to do. So these are some of the basic features that's kind of like the five-minute overview. There's also, let's see, so here's a basic overview here. Our crypto is we want to make it modular but right now we support TwistedEdwardsCurve and Shot3 and these are all implemented on a Cybos Plus iOS Android and JavaScript and that was quite a tremendous effort to get these libraries to work or to get the digital signatures to be exactly the same on all these platforms because there's a lot of differences in base 64 encoding etc. So it is quite a lot of work. Let's see, we also have a new consensus algorithm which is kind of one of the main features I think and I think later in the meeting there's going to be some talk about Java based smart contracts and so that's kind of what we're doing is with a sandbox JVM. So we should be able to make this interoperable with what Java based fabric smart contracts are. Here's the basic architecture here. So we have a peer-to-peer network at the bottom. Things like data validations and basic validation is done in C++. Consensus is in C++ that's in our algorithm Simeragi and for database we just use level to be DB, you know modular and then we have a sandboxed Java VM and the API server is going to change but right now we're using Pro for just REST API. We want to support GRPC in the future so we already are looking into that not just for the API library but also for the iOS Android and JavaScript libraries. So that's something we want to support in the short term basically to be as compatible as possible with fabric. Let's see we're working with a few different institutions so we have the co-sponsors on the proposal but then we also are doing collaborative research with the University of Aizu in Fukushima prefecture. We're working with Koldu in Israel and with Glockon which is a think-tank here in Japan and with entity data and also Rakuten's securities and Sampo Japan which is one of the big three insurance companies here. We're working with them to issue things like insurance contract derivatives on the blockchain. So that's kind of the basic overview of the proposal. I don't know how much time I have so I could talk for the next few hours if you want but no one's stopping me so just keep going. So our consensus algorithm the basic idea is sorry I need to write more documentation but the basic idea is that for BFT for different Byzantine fault tolerant algorithms there's two different broad categories. There's broadcast-based and there's chain-based so broadcast-based are algorithms like PBFT, sieve, chain-based there are many algorithms in the literature. The algorithm we based our work mainly on is the one called B-chain so it's by C.C. Duan and this this algorithm is it's interesting so the idea is that instead of broadcasting the transaction to all the peers for the common case this this flow chart shows the common case with Alta Byzantine failure. You take the broadcast into the or take the transaction to the API server you broadcast it to all the validating peers and then out of the validating peers you only need to collect 2f plus 1 signatures so in this case if your four signatures and f is equal to 1 then in this node here server 3 is what's called the proxy tail so they're the one that you know signs the transaction or collects all the signatures and then broadcasts the signatures that everyone assuming no Byzantine failures and so here you instead of having all four servers validate the transaction and sign you only have server 1 2 and 3 2f plus 1 validate and sign server 3 clicks and then once it gets to f plus 1 signatures it broadcasts to all the nodes and then you can go back and contact the client if you want and also yeah each peer commits the transaction after receiving 2f plus 1 signatures from the proxy tail so that's the the basic ideas you go down in this chain to do the transaction signing and then broadcast once you collect all the transactions as opposed to algorithms like PBFT where you do lots of message passing around the network so this is the the first draft of the algorithm and it's it's very similar to the B chain algorithm in the literature that's the the basic story here I'm I've been working on okay so maybe here so I've been working on a specification for v1 which will hopefully show the the overall vision that we want to create so I've been writing this the idea is in addition to chain code so we want to practice what's called a domain-driven development so we support basic chain code transactions like well basically a chain code life cycles what we want to support so deploy invoke update destroy and in addition to the chain code flex that gives you lots of flexibility we must also want to make it really easy to do certain tasks related to use case for example creating digital assets and sending these digital assets to other people so to help facilitate that facilitate that we have different transaction types domain is like a domain name type of registration and then assets are associated with the domain name and then can be transferred to others arbitrary data can just be stored in blobs and then members of service we want to make it decentralized using just transactions on the ledger for adding and removing peers this was a discussed in Amsterdam at the architecture working group meeting and I think it's the right way to to do this type of thing so and other things that I want to write so I'm still working on adding word to this draft so at this stage there any questions hi this is Greg I was wondering so so the basic algorithm that you implemented for consensus you know I've seen designs like that before and generally one of the biggest problems with that approach is what happens when you have disagreement right so how how do you reconcile the last stage of commit that so I mean I understand the point that if someone was going to say verify a certain block that contain a certain number of transactions in there and if everybody submits in the non-Byzantine case a signature for it then it all works smoothly but what happens when you end up having some level of Byzantine type behavior introduced so like perhaps some nodes don't even receive some of the signatures and so on and so forth like how do you how do you it so here's a scenario right so say you gather two f plus one signatures on server three but server four never never receives the threshold so they don't make they don't see it as a committed transaction how do you propose that that would reconcile the state so that everyone knows that a new block was was committed to the ledger okay so all the chain or all the notes in the network know the order that the servers should process the transaction and they know who should we should broadcast so I didn't really explain all that part but the the order that the servers are processed the transaction is based on the the distance between each server's public key and the nodes or the transactions private sorry hash so that the transaction hash is a numeric value and each each server in the network has a public key associated with it which is also a numeric value so it just takes a the distance between those those values in order to get the the transaction processing order so all the nodes know who should broadcast at the end and they also know that they should you expect once they sign a message and then they give it to that node they set a timer and then within let's say two seconds if they don't get a response then they you know they know that this server either is faulty or some of the servers are faulty and there weren't enough signatures so what each server will do is then go and send their transactions to the subsequent nodes so in this case server 4 so this this you know for node network can only support one Byzantine failure but if you have multiple Byzantine failures and multiple nodes or more nodes then you just can keep going down the chain until eventually either every one time is out and commits a failure or you get enough signatures for the transaction yeah so I'm popping up from the from the actual algorithm itself what so one of the things in reading the proposal I was having a hard time figuring out is exactly what this is is it a library they could be incorporated is it a standalone ledger and just just a concrete version of that question so I'm assuming that if I use your consensus algorithm if I want to pull that in then I would also have to pull in all of the peer to peer communication code especially given what you just said about expectations or server ordering and membership so how modular is it really is this something that I can actually pull pieces in independently or do I have to take the big chunk okay that's a great question so to answer the first question this is an independent standalone ledger but you know we don't want to just I don't know need to fragmentation of the project but we also want to create an additive you know we want to make everything componentized so that it's additive to the other projects as well I think the vision that we're moving towards or that we want to help promote is maybe not this early stage but in two three years I I see hyper ledger maybe is having you know not not many different projects but rather more of a standard protocol and then different components that implement different aspects of this protocol so that's kind of what we want to move towards to answer your second question about the modularization or the ability to take out different pieces the consensus is done on what are called consensus events which we wish they're just abstractions it doesn't matter what people are trying to get consensus on now for there has to be some kind of abstraction for you know peer communication and the details of that don't have to be done you know using so we're using Aaron which is a messaging queue but you don't you don't have to use Aaron you can use any kind of protocol for messaging and so basically we just have broader functions to contact like different nodes on the network just assuming or the way we do it is we get a list of these nodes from the membership service so all the validating peers have to be known but that's the only limitation really but I think any kind of typical BFT well okay there's there's a few cases where you don't have to know all the peers but for most algorithms you do have to know all the peers that you're working with so it does I mean it sounds to me like there's quite a few interdependencies between the modules at least in the current implementation and expectation that's right yeah okay one more quick question on that what is your what's the maturity level of the code is this something where you're deploying POC's right now or is this still I mean that the architecture diagrams that I saw on the code look preliminary is the code advanced beyond the the documents or what's the current status okay so the code currently just uses Aaron as a peer-to-peer messaging queue you do have a basic implementation of the consensus algorithm but that's still being changed to to add you know different validation checks for state global state using more culture so once that's done I think we are in a pretty good shape for a basic version that can be used for things like POC's we are using a limited subset of this for some POC's at the moment but I mean yeah this is a work in progress but I think the reason for proposing this into incubation at this stage is to help guide the overall architecture in the design rather than us doing everything on our own and then later saying hey here look what we built thank you so long there go ahead one question I sorry is a you mentioned at the beginning that some of the motivation came from your desire to include the C++ community in the and you know in specific clients like mobile to participate on the Hyperledger project but I'm curious you know what what motivated you to go in this directions like say correct like did you feel so you couldn't you couldn't implement say an iOS client or a C++ contract in the existing frameworks like was there a specific reason why you had to go in this direction or is there you know what's what's your thoughts there okay that's a good question so we've kind of felt that within the current framework it's hard to you know well the API changes a lot for one thing and lots of things are still changing including the change switch to GPC so we kind of want to kind of create our own platform that we could you know have more control to kind of try different things and kind of experiment we also want to make something a little bit lighter weight so instead of using something like Docker we use just a kind of sandbox JPM so that's the basic motivation another thing is we start working on this around well around March I guess and or it's when we start proposing it and at that time yeah I think there's a lot of difficulties with doing it on current projects but at this point in time it's I think it makes sense to have kind of a smaller project with a code base in a different language that can you know slowly adapt to more standard as protocol so I you know I haven't had a chance to fully digest this so I don't have an opinion one way the other but one calm one thought I had just based on the current discussion is that you know if you're worried about churn I mean this is only going to add more churn right that be more diversity more choices and more fragmentation just naturally from having another choice and the other comment I would have is that you know I I don't know as much about sawtooth lake but on the fabric side I know you know there's nothing that precludes C++ chain code or non-docker based containerization or any of those kind of things so you don't necessarily have to not use the framework for those reasons that being said it you know it is a fair point I understand things are turning a lot and and that's something we need to converge on stabilizing as we move forward yeah regards to fragmentation I think fragmentation in the long term is it's a really bad thing but I think at the beginning at the stage this is kind of time in the project you know still trying out new things and the direction isn't completely decided yet I think there's a lot of value in trying lots of different things and then you know taking the best of the different ideas there put forth I'm gonna go so I go ahead this this is Todd I'm just gonna jump in quickly here I know we're about 10 minutes over I think two of the TSC members have dropped in it looks like Dan is needing to drop now as well so we're well undercour them at this point given that and given that this is an important topic my recommendation would be that we move some of this discussion to the mailing list a lot of these questions to work through this over the coming week and then revisit this topic in next week's TSC meeting as it seems like there's still some questions that people want to kind of kick the tires and get answered does that work for for those still on the call yep yes I recommend that we move this discussion at the beginning of the call rather than the end yeah definitely and I think things got kicked off a little slower today than that we would have hoped so agree we'll get this up front and then the only other things workgroup updates if everyone can just send that over via email just as a response to the minutes that will go out and then the last question Satish are you still on my one question is do you prefer for me to send a video of your demo out or do you want to get slotted in for next week to walk through your Java chain code demo okay about the video can you hear me yes about the video I will I will email you again if you're good to go ahead with the video but yeah I would prefer to do a demo so that I can take questions and then answer them you know so yeah okay sounds good and then before we wrap up any any questions from anyone else I know Chris has had to drop as well I think decision was wise with regard to decision on the project here I just wanted to share with those who weren't at the meeting last week that we actually had a discussion in relation to this which was about should we have some form of criteria to decide what qualifies as an incubation we've talked about incubation execute area and there was this question well should you be some kind of entry criteria in a way and I mean to be to be fair I don't think we really got anywhere with the discussion but I still think you know this was an interesting discussion that people should be aware yeah the I mean I think there is the entry criteria which is basically a sound proposal that makes sense to the TSE members but the problem is that we are getting loaded up with so much stuff that you know like right in the beginning we talked about 40 minutes about wiki and this and that so I think there might be a problem if the TSE members cannot really engage and you know because it really demands high level of attention if you're going to vote on this kind of stuff this is you know and the landscape is moving so fast like next week for example you guys are moved this Erohi thing to next week plus you're gonna have the demo the Java demo you know it's basically trying to fit a lot of stuff into a small you know one and a half hours it's possible yep yeah agree VIP and all good points and I think make kind of good point as well with moving this up to the front so for for next TSE we'll keep the kind of updates and administrative stuff to you know a minimum and really move on this more more critical stuff up front okay sounds good all right any other questions or comments before we wrap up sounds good thank you everyone for your time minutes we'll go out later this afternoon thank you