 Jonathan Kelly Okay, thanks Kelly We're just waiting for one more to join us Chris you make out okay in the storm We did we were very lucky as we're on the East Coast, so instead of getting a direct hit we had a Only a cat one Equipment here We had lots of tornadoes. Oh, it was a pretty scary We came through okay just some minor tree stuff. Oh, that's good to hear. Yeah Right, it looks like we have Greg on the line now as well so Can you guys still see my screen? We can or I can all right, that's good Of course due to the The wonders of go-to-meeting half the screen is covered by the stupid widget All right, let me let me close that and we'll go back into present mode And we'll hit the agenda All right, so this is our agenda for today So good morning. Good afternoon. Good evening everyone um On the agenda today, we've got the usual hackfest planning. So we're gearing up for the Chicago hackfest And I take a tracy you'll cover that Um planning for the Lisbon hackfest. I assume that we'll have registration linked up soon um Then we have a proposal for hyper ledger inter ledger Java That will go through and tracy. Do we get somebody to present that? Uh, so i'm not sure if anybody's on the line or not chris Yeah, I even hope alia from ripple and I think some of my colleagues from uh on the line Okay, excellent excellent And then the project reporting discussion. Is there anything else people would like to have on the agenda today? Okay, if not, let's uh kick it off. So tracy over you All right, thanks chris. So a hackfest uh is coming up Next week in chicago So if you have not registered yet and you're planning on attending, uh, this is pretty much your your last call for registration And then uh, if you are attending and you'd like to add to the agenda We do have a draft agenda that's available For people to add topics that they'd like to discuss And then as chris mentioned We are working on the final details for the Lisbon hackfest and making sure that we have information about Places that people can stay before we bring up the registration site But expect that to be showing up very very soon What's the registration count at this point for chicago? I checked it yesterday. It was 104 People have registered for chicago. So yeah, good crowd Yeah, that's good. Um And uh Just as a reminder to people, um, you know, we put the agenda link up and basically we try and You know sort of crowdsource and then have you know, actually an unconference format But uh as brian and I have both Made note of in the past what we'd like to do with this one is have it be a little bit more hacking and a little bit more less yacking and And so, um, you know getting some items up where You know teams are maybe planning on getting together and doing a little bit of experimentation exploration into how we might get some chocolate into the other teams peanut butter um and make some rices cups would be Preferable to having A bunch of dog and pony. It doesn't mean we can't have any presentations any uh You know sort of more discussion type topics, but um Right. Yeah, not a hackfest Um, but again, we'd really like to have Things be a little bit more about what can we actually do to you know, encourage Integration and or interoperability across the different projects between the different projects And uh, and if you know people need to have a working group meeting And then preferably those are done Not at the hackfest itself, but during a call in the week and then they can get together and Have some other discussions and so forth, but again less Try try not to have it such that we are essentially Taking away from the opportunity to get together and and actually uh You know have much much more of a Integration dialogue if you will between the various projects then Then we have in the past Chris could we possibly do something like not schedule meetings during the afternoon then? Yeah, I think that is likely to be One way of approaching it. Um, what has happened in the past is just everyone wants to have a meeting And agenda just fills up Right exactly. Yeah, everybody wants to go to the identity meeting and Right, exactly. Yeah, I agree with Arno who just commented that no real hacking will happen Spontaneously, so I agree. I think we probably if we want this to happen. We should probably say, you know After lunch, you know, we we don't have meetings and presentations Um or something like that or maybe before lunch or however we want to do it Because I think otherwise we will just You know, we'll get scheduled bloat which Kind of always happens. We always say we want to do more hacking And then we never get to it because you know, the meeting's just kind of Right and nobody wants to miss the meeting, right? So I think if if we want to do this we should I mean, there's just a suggestion. I mean, there could be other ways of doing this But I think we need to have some kind of firm structure in place To enable this to happen. I don't think it will happen if we just give it lip service Can I uh Well, there's two two thoughts I have one is um There are likely going to be people who show up who are you know, still on the on the learning curve when it comes to the different technology Different projects and so it's still I think useful not to have a Not to have a meeting but to make sure there's folks available who can help new devs up that learning curve Um, uh, so just want to create space for that recognizing folks like that will show up And then secondly, I remember mentioning to chris. Um, wouldn't it be interesting to have as part of like a structured recommendation? A mandate that says, you know If you're chosen project is fabric Your job Or one of your goals at the access should be to come up to speed and get a running instance of another project at hyperlature, right? To intentionally dive in to You know, if your project is fabric to dive into burrow or dive into sawtooth or indy and and Work with those folks that have showed up from those projects, but but let them also then dive into your project, right? And it might not be pushing me on to look forward on hacking and and knocking out jira defect That sort of thing, but it might really help with the Conversation about cross-project, you know integration any more on hackpest Not a hack Okay, uh next up is the interledger proposal interledger java Um, can somebody paste the link into the chat so that others and then we'll uh go through And is there anybody who would like to Take presentation mode Uh to present anything specific Hi, this is adrian. So, um, we haven't prepared anything specific in terms of presentation. Um My understanding was that we should join the call and talk through the proposal document with the members of that tsc That's fine. If you want to do that, we can we can do that and you can just Tracy, maybe you can just uh Have the proposal up and then scroll through as they need All right. Thanks. So so um, so my name is adrian. Uh, I work at ripple The interledger product project, uh started at ripple. It's it is a w3c community group project and has focused on development of a protocol uh, the group's been in existence getting close to two years now and One of the challenges we've had as a standard group is that we're building a lot of reference code and uh, this was not an obvious place Where this code could be developed and maintained and fall into a framework of good governance and contributor management and so on so Uh, about a year ago, we joined the js foundation and a huge chunk of our reference code, which is javascript code in a separate project called interledger jf at the js foundation Now obviously because intelligence is a protocol, uh, there are other implementations starting to Be developed and and probably about 18 months ago We started looking at a java implementation I've done some work in it personally as well as a number of colleagues from ripple But uh, colleagues from everus and entity to coma started contributing A great deal to the java implementation And that's evolved quite nicely to the point that we thought it was a good time for that to also find the home and have a project where that could continue to evolve at the a Java stack that is focused on interoperability between Distributed ledger or ledger systems at least not just distributed ledger. So that's that's really the the background Interledger itself is a fairly simple Protocol it establishes a A global namespace for accounts value holding accounts or digital asset accounts And it establishes a simple protocol for what you could think of as synchronized atomic swaps between different um different systems, so It establishes a standard for the condition um that you would use in like a hash time lock Contract or as we call them more abstractly a hash time lock agreement and uh, and what the Fulfillment of that condition would look like by putting this all together we able to Perform what are in effect? Payments or transfers of value across multiple systems that integrate together. So to address some of the key questions I think would have come up in the document Yes, uh, interledger is is primarily a payments protocol. So while there are a number of systems um on projects within the hyper ledger Under the hyper ledger umbrella that are not payments focused there Uh, during complete smart contract systems Interledger is primarily primarily about integrating those systems For the purpose of transferring, you know value that is underwritten on those systems um, so it's it's Not clear or certainly hasn't been explored. Uh harvest might apply to other things Um, another question was asked around lightning. So, you know, how similar is this to lightning and and I think It's intentionally quite similar. It has a number of it. I would call it an abstraction above what the lightning network is in that it um The the the condition that we use for our contracts is Is similar so that a lightning network could form part of a group of networks integrated with interledger But it's it's sort of an overlay on top of that So you you could have a lightning network as well as another network underpin for example by uh, indy or burrow and another network and by Um, you know a traditional payment system and you could integrate all three of those. Um, using an interledger protocol I think that's the gist of the the main comments I've seen but uh, my colleagues from uh, it's our Arab era from Everest who's been the main proposal is unfortunately unable to make the call But I know some of his colleagues are on the line and may also have some things to add Juan Carlos. So are you Uh, I'm happy with my with my presentations as far as anything you want to add to that Hello, I'm Juan Carlos from Everest Uh, yeah, really your explanation was really good. I don't have anything to add In that case, uh, any questions? Hi, this is uh, dan middleton, uh question on the dependencies that this would imply on the On the existing blockchain frameworks or conversely whether The intent of this proposal is to provide Uh, all the adaptations necessary and contained within the interledger project rather than implying new code on the infrastructure projects Right a great question. Thanks dan. So there's been, um Two ways we've integrated with existing systems to date Really the the one is if if the system is able to evolve to adopt The standards we've defined for The escrow or the you know the holes or whatever you want to call them Um, then it's it's possible for that system to be, you know, we would call it natively supporting interledger and you and you could have Um, very simple integration from what we would call a connector. So a system that that um is accepting Transfer on one system and making a transfer on another as part of facilitating the payment The other way to do that is To write plugins That you that uh are specific to that Ledger so they speak that ledger's protocol and they abstract away a lot of the so we have a I guess you could call it a spectrum of what we call hash time lock agreement So you you may be familiar with the concept of hash time lock contract, which are part of uh, how lightning works um, we've documented sort of a spectrum of what we We sort of call an abstraction of those which are the agreements and those vary from right on the extreme You know a system that natively supports these um time lock contracts right across to one that doesn't but where the two entities transacting across that system actually establish An account with one another some trust and so Well, the underlying system is underwriting that relationship But the payments themselves can I actually just exchange directly the payment instruction? So so there's a there's a full spectrum of those different Agreements and it's quite possible to implement Intelleger over a system that has absolutely no sort of native support for it In terms of the work that we intend to do in this project, um To date we've defined what we call a standard ledger adapter interface, which Which we've implemented for the The reference ledger we call the five belt ledger So all of that have been implemented in in this project already The plan would be to catch up with some of the javascript reference implementations for existing ledgers and then also to focus on um ledger systems within the hyper ledger project that's inappropriate. So That question was asked, you know, would we focus on all project? How would be prioritized? and I think that would come from the hyper ledger community in terms of their interest in in Working with us to build that integration so Again, I'm still not clear on the the specific implementation if I could If you could take us a Another lower level. So from the inter ledger point of view, as we said, this is implemented in java If we were to support that say from fabric if we were to support this Would we then implement the plugin or the adapter that have been called our connector that being called here in java or the interface is Or would the interface be rust or bottom buff kind of interface that is neutral Right. So um, we're in the process of defining an over-the-wire interface So a binary interface that would be You know stack agnostic would allow Two entities to interface with one another If you know one's rust and one's java or whatever the case may be So our plan would be to implement that interface in java and then be able to interface to interact or connect with Another entity that could be implemented in something else. So some of the existing javascript implementations for the underlying ledger system It's possible to do nothing but it's possible for us to If the ledger system itself Wants to support this concept of escrow, then it could build that into the ledger itself. But As I understand the fabric project, for example, it's a it's a smart contract system So one would imagine that if you were using fabric as the underlying ledger between two nodes So you have two entities on the inter ledger who are transacting with one another and fabric is underpinning that Then I would expect that there would be a contract written that runs within fabric that is specific to that relationship and that contract would be some sort of Value transfer contract that encapsulates the the inter ledger logic around escrow and it would be written to use the same um Nice piries and contract, um, you know triggers and so on as as we've standardized on Right, right. Thank you By the way, that is exactly how we've implemented our proof of concept of a theorem okay so in the case of the Sorry in the case of um You know just i'm thinking about the the kind of four main platforms that we have right now are five if you You know if we extend boroughs out to a platform um All of them are very general um in the semantics that they have um, and that they use um, I mean, I can imagine one way that that that a plug-in becomes and Just to talk on on saw two terms it becomes kind of a library that you could add to is To a transaction family that would support the appropriate Kind of escrow capabilities How do you imagine? Inter ledger playing with these others that are more general purpose Is it just a subset of usages or is this a general purpose facility that that? I mean, I I'm just having a hard time kind of wrapping my brain around what it means to incorporate inter ledger Right. So so as I said, we haven't explored anything beyond the value transfer use case That that was really what inter ledger was designed for so for a general purpose system If that general purpose system is being used to Um, underwrite some sort of value, you know a token's being issued and that's being passed around or whatever the case may be Then then I think the use of inter ledger is fairly straightforward the the way value is transferred on that system um, if it's designed to Have a two phase transfer where It can be put into an escrow with a time limit and then released given a cryptographic key And those follow the inter ledger standard. So the you know that the key is a is the pre image of a char 256 hash Then it's very Straightforward how you would use that system if you have something a more generic use case Um, that's to be honest not something we've really explored and I'm hoping that's something we can dig into as part of this project Is to understand where the same principles? Could be applied for you know for new use cases that are not specific to value transfer Yeah, I can I comment that I added the comment that I added to the document was basically something about is there a way to generalize this to a kind of multi ledger atomic commit Which is I mean that's essentially what you're doing With the with the escrow Because this is This is the phone also from from ripple. I'm one of the co-authors of the digital white paper Um, just wanted to to comment on that a little bit. So The way do we look at it this fitting into sort of a larger transaction system? Is whenever you want to make a transaction want to move assets around? You really don't want to care Which ledgers these assets are on because they could be on different ledgers and at that point you need to figure out how do you Find liquidity between those ledgers. Someone has to take the risk of converting one asset for another And so if you're writing a contract, let's say I owe you $100 Ideally you would be able to code that contract and say like I pay you $100 without having to care Which ledgers we use respectively and uh, which? Connectors are out there that providing liquidity between those ledgers So intelligent is intentionally designed with these hash tech Unlocked agreements so that it can tie into a higher level contract because that high level contract can then acknowledge receipt of the funds with this hash lock and then execute the payment so um, I would also refer to Aspect that we've written at the um and introduced at the itf called crypto conditions Which I believe has been referenced in that a quarter white paper as well as in the chain white paper So I would also point to that as something that could be a primitive to tie these different systems together Thank you Yeah, so so one of the first things we actually implemented within the project is a a java implementation of crypto conditions If you'd like I'll try and find a link to the itf internet draft Quickly and I can post that in I would like to see that. Yes. Thank you So this is good. I was actually this is ono I was going to ask you what the status of the spec is because I remember you guys started Looking into the d3c to evolve the spec and then figure it well. It's a protocol. It belongs more to itf So how much progress have you made on that front? hey ono so so we continue to operate under The umbrella of a w3c community group um, and and I guess part of the challenge we have is that there's so many streams of work going on as I say we we've got um code you know code We're writing open source code and that needs a home and then we've got a bunch of branches of where this work is going so on the one hand there's work going on to Figure out how intelligent would be applicable in the web payments work and that's very you know, that's very applicable at w3c On the other hand, there's more generic primitive like cryptic conditions, which we presented at itf and Are planning to be in singapore Later in november as well to to potentially Provide an update there. We also did a box at itf in bilan a birds of a feather session where we presented intelligent there was a lot of interest the challenge we have is that the the attendees at itf The companies that attend are not the same People who are interested in intelligence. So whereas it's kind of It's an appropriate type of audience. It's the wrong companies or people involved and so we're trying to build up some momentum around the project to Either attract those people to people from the companies that are you know, hyperlager members as an example of a of a set of companies would be interested in you know, contributing To itf or or finding an alternative place where some of these standards could be established Okay, thank you. I can understand the challenge of finding the right venue for this Okay, so the intelligence project is totally led by the W3C now. So if we accept it as a hyperlager project How would those two two organizations collaborate with each other? What's the expectation? Which which two organizations are you referring to? The hyperlager community under W3C, yeah Right. I'll give you a bit more background if I can interject because I'm very familiar with that part The W3C community groups really are just public forums. They are they they are not often go work within the W3C Correct. So the W3C provides a framework for us. It it provides us with a mailing list a blog It it it helps us to establish contributor agreements. So everyone who joins the group is by default Had to sign the contributor agreement and it basically just protects the standards development work that's going on in that group from You know from malicious acts. It's it's not it's not In any way putting us by it doesn't by default put us on a standards track within W3C So as I said, there's streams of work that we're busy with that may be appropriate at W3C And we're in the process of Building up the charter for the web payments working group where some aspects of the interledger work may Fall into that and that would be specific to payments and browsers. So it's very different for example to what we're You know working on at a you know generic protocol definition sort of forum On on the other hand, you know, we have something like the crypto conditions draft which we presented at itf And for that to become a standards track document We would need to attract a number of other people interested in forming a work group around that work and and progressing it and and at the moment We we haven't been able to find people at itf who who are already attending itf Who have an interest in that so this is part of you know, the process that's going on now is to find other interested parties in the work and and Find a forum that we all agree is the correct place to take the work Risk to introduce those conflictions among those different organizations, right? I missed that. Sorry. There are a few people talking over each other if we Make the project under the umbrella of different Organizations, there will be some risk To introduce the conflictions Sure, but the the focus within hyper ledger specifically is We want to we want to have an open source software project so the the the deliverables of this project will be software code and and the The intention or the goal is develop code that's used for interoperability between these ledger systems and the Today the plan is for that code to be an implementation of the interledger protocol You would have seen the discussion on the mailing list with Brian around Naming and and I think part of the intention around picking a generic name like hyper ledger quilts Which I think is where we settled is that you know, we're going to start this Project on a roadmap of we want to interoperate these systems And right now the how we do that is is interledger, but that could evolve over time And and the specific deliverables will just be you know, it will be code will be will be java Intent is the intent today code for for doing providing that interoperability in terms of the actual protocol itself That's not happening within this hyper ledger group. The development of the protocol itself Is happening within the w3c group today and could happen also in the future But obviously our hope is that if people are getting involved in hyper ledger quills They'll take an interest in the you know the evolution of protocol itself and and contribute to that as well Okay, thanks So Adrienne speaking of quill pit set the name that we're ending up with I know there was an awful lot of discussion around the name So we have a we have a bi-weekly we have a bi-weekly call The ever skies and myself and some of the guys at ripple and other contributors And we had one yesterday and that seems to be the name we've everyone settled on It's it's kind of the the least likely to cause friction. I think was was probably where we ended up And and what I'm going to what I agree to do is I'll get our design team at ripple to see if they can Put some ideas together for some sort of branding around it because we did the same for the interledger j s project We took the same color schemes from the interledger logo and produced a new interledger j s So logo and so on and and and and that helps to sort of Provide an idea of of what the the brand if you like will look like on the project So we're going to do I'm going to do that this week and see if I can share something Next week on on what that might look like Okay, and just out of curiosity you guys talked it all to stellar and I We have That I know of we've we've had a lot of interactions with a lot of the other blockchain projects As well as non blockchain payments payments businesses you You'll have likely seen we had a workshop in Berlin earlier this year where we did a big demo and we had people from e-cash and Bitfury and so on there and we did a Payment that went over interledger went used interledger to pass over ethereum bitcoin XRP etc. So You know, we we're not intentionally excluding anybody but we've you know, we've basically been engaging whoever we have the resources To engage in anyone who's shown an interest in participating But as yet, I'm not aware of anyone who's built a stellar integration. Well, they certainly if they have no one's brought it to the group Okay, could you talk a little bit about the resourcing? I appreciated seeing that there was some full-time commitment of resources When I went and looked at the activity on the existing GitHub project It wasn't obvious to me though if that was Going to be an uptake in resourcing or if those individuals were already active on there Uh, right. So I'll have to ask Juan Carlos to comment from ever aside But from Ripple side We have a number of no one at Ripple is on this full time Although we have at last time I think four engineers who are all contributing myself included um, so that's that's sort of the Where things sit with Ripple. I I think of my last conversation with his I understood that there was going to be some full-time Commitment from some engineers that side, but I know Juan Carlos can add color to that Yeah, absolutely from the every side originally there was just Enrique who is our lead architect who I think is in this call as well and and me But from our side, we're we're also planning on bringing in people from Latin America from Japan from From a few different offices within engineers as well I don't have any specifics yet, but I can tell you like maybe increase the team in Everest by 10 20 people is the objective Okay, that's that's interesting. Maybe the proposal could be Amended a little bit. So it's it's more clear on the engineering because at least at the moment It says pretty directly that the Ripple Engineering would be full-time. That's kind of the the read on the the list of names there I I think you you know between all of the um Engineers at Ripple you probably end up with just over the equivalent of one full-time or maybe one and a half, but that's Probably going to fluctuate Okay, and then um When we look at the activity on the existing github project It doesn't look As active as what what that many engineers would would maybe imply So yeah There would definitely be an uptick and I and we've gone through fairly quiet phase at the moment where a lot of our energy has been um looking at the protocol stuff and and uh To be honest The the when that's happening The majority of the proof of concept work is happening in the java script stack and then we Reimplement that in Java sort of once it's once it's settled. So We have gone through a bit of a lull of late. I'm hoping that if we can, you know, if we can find more contributors on the the Java implementation We can even you know use that to Poc some of the ideas or even the you know At least be on feature parity with the java script stack and potentially even exploring new things In the the java stack that that haven't even um That are not in the java script stack at all And where's the java script stack? Held It's in a github project. I think the github group is just called intelligent jf So you just go to github.com slash intelligent jf Okay, is that under a similar kind of governance laundry right now that whole everything in there is Actually also part of Linux foundation under the jf foundation Oh, that's right. You did mention that up front. Yeah. Yeah So so we'd like I mean, we'd like obviously another implementations to to follow us on the path where they have a You know, they form part of a project that has a governance model and you know, contributor management and Standardized life and thing on all of those kind of things Anyway, github activity might be a little bit deceptive because a few of the developers like to To develop at first on their own personal github and then fork out to To the main one so you might see Which are like just one commit, but might might be a thousand lines stuff like that. Okay. Thanks Hello, I'm Enrique from Everdeez I just would like to add that from our every side There is also some other groups That are already working with hyper-legia technology. Well, in fact, I think entity data is that is our Father company. Let's say it's already part of the hyper-legia And I cannot say for sure how many people are really working We're already working on hyper-legia because we are more than 18 18,000 employers So I don't know what's the the activity of all the group But I I know for sure that there is already people working on hyper-legia So it will be interesting from our side to To just make ILP work just for business For business for our home business interests So that's all okay, so thinking again on the different aspects of The the javascript project being elsewhere and the need to find a home for the the java project I'm not clear if if the goal in bringing that project under a hyper-legia umbrella is to have a governance model over code that is going to prioritize Existing payment networks like bitcoin and so forth Or if the goal is to bring it under hyper-legia so that you can integrate hyper-legia Stacks or there's other possible answers to that question, of course so from my from my perspective the goal is More generic, but I think the reality will be determined by who wants to contribute to the project yeah, so The jf foundation is actually a project under the linux foundation Although I think maybe it's managed by That's correct. Yeah, it is yeah, so You know, I suppose that you know, it might actually make sense to sort of Because they're, you know, their focus is obviously javascript And And not other languages that maybe it might actually make sense to sort of Have that project come over here so that it's side by side so that you just have different implementations of essentially the same thing and it's easier to sort of keep things Sorted out in a single place. I think dan, you know is highlighting an important aspect of all of this is that ideally instead of being scattered all over there's some sort of focal Point for the work itself and then that might actually help to draw more attention and more participation then You know and providing the forum that I think you guys are actually looking for Yeah, I hadn't considered that as an option. Um I would be interested to hear what the jays foundation guys would think of Yeah, I think that's something that brian could talk to chris about maybe And and and you know, I Um, I didn't want to you know, tie this to that. Uh, I've You know as a positive experience figured if we did if we brought this in as a positive experience and that's the basis for for going and Seeing if there was interest there But you know, it also seems to be happy over there. So I think yeah, I think the one advantage of them being separate is that they can evolve separately Ultimately, I think we're getting to a point where the intelligent protocol itself is going to stabilize And and not change dramatically and then the reference implementations will have some core code libraries that you know are Not changing dramatically, but there'll be a great amount of energy into You know periphery stuff like integrations into Existing systems and so on and I think those are going to evolve separately I would be nervous about lumping the stacks together if that creates an assumption that you know, if someone's building a Fabric integration and the java stack that that there's a need to have a fabric integration in the javascript stack as well um, I think that's Probably not likely to happen, especially if they start to be typed integrations that are built in the technology of the of the stack itself Of the of the Of the ledger stack, I mean so one way Yeah, one one way I would like to see the I mean my my way I visualized this evolving was that you know hyperlegical to the project for interoperability of um You know ledger systems and it implements the interledger protocol as opposed to it being This is an interledger project It's it's it's another implementation of this protocol Any other questions for adrian and the Any others? Yes, it's this is bippin from uh, me and So we spoke briefly about the split meaning one You know the hyperlegger project The interledger was supposed to be inside hyperledger And the deliverable would be a code base And then for standard purposes. You will be uh housed under ietf We also have some working groups under Hyperledger that is supposed to be cross cutting and providing A guidance at least on standards for all the projects that are being under the umbrella of hyperledger so How would that operate With respect how would the interledger operate with respect to You know this this Split which which we had envisaged and how how would you interoperate with? You know the working group Working groups in hyperledger So So I see two interactions there if I understand the the question correctly There's a interaction between this project and other hyperledger project And there's an interaction between this project and whichever Home we find for the standards development on the first I think I I think it will be a valuable two-way interaction Where the existing projects can provide input into into this project On how their systems work and where You know what we're doing is applicable and also you know assist in developing integrations for those projects You know and it I'm hoping that you know contributors from those projects will actually contribute into this as well and say well We quite like the idea of an integration for fabric or for you know borough So we'll actually contribute the codes that that provides the plug-in or the adapter or whatever model We go with To do that on the other hand the interaction with the standards body I think would also be a two-way thing in that You know the standard is being established within that community around how the protocol works and you know Other aspects Standardized aspects of of the interledger itself, but there's also got to be feedback from implementers And from implementation is that say well, we've tried implementing this and it's actually problematic for these reasons because when we integrate You know fabric and borough for the specific use case This aspect of the standard is problematic and and that that should also feedback into the protocol development Work as well. And I mean those have been tightly coupled Um processes today. So we've had you know a very There's quite a strong overlap of people who are building the implementation and working on the protocol And so it's been a pretty tight feedback loop Obviously as the project is matured and we we end up with more and more implementation That becomes more disparate and and we'll have to manage that But that's certainly mine My hope is that everybody who takes interledger and says I want to build an implementation of this I have a use case in mind or something specific. I want to do with it that As they do that they feedback into you know the community and say well, you know, this doesn't work Or this does work or here's the suggestion to make things better Thanks. I think you know overall this is a welcome development because As you users And not the developers of the of the DLT's We have an interest in promoting interoperability and Some of the Some of the questions, especially around identity will be You know, because because that is needs to be nailed down as to how the process the DLT boundaries Uh, I know that you guys You know, you you have a pretty simple Definition of certain Things and that is great because you know with a simple escrow Our time lock mechanism You know being able to cross The LTS is a wonderful thing Yeah, I think I think that that that process or that time lock Process can be applied across many transactions doesn't have to just be payments as Stefan alluded to before and and it also provides The great primitive on which you can build smart contracts And so on so so I really I'm I'm hopeful that by bringing this into hyperledger We can explore that stuff more deeply certainly, you know You've had a payment focus because those that's that's driven by the nature of the contributors to the community today That doesn't preclude that from becoming an important part of the work going forward Well in the in the classic model, uh, if you just um, if you can just model a um identity and an asset Then you can have start up having transactions between identities of assets And since cash is a special asset and since this whole thing started out with cryptocurrency That's why I think we see the bias towards, you know The payments or the currencies But a generic model of asset Will Not be that far off because we have this Generic smart contract languages, which which will end up having to model an asset anyway to do anything useful So, uh, even though they do not have embedded Cryptocurrencies This will still uh can be built on top of all that anyway So I think this is not the easiest setup for sure because you have basically Working group developing a spec that gets published in itf and they implemented in javascript with the ts foundation And implementation in java with the hyper ledger But This being said my experience is, you know, those groups have a inherent interest to keep all this in In place, especially repo and so if repos, you know, if repo is involved in all of this This separate effort, I think they will keep it together And you know, I I do think there is a natural interaction that happens between implementers and the spec writers and You know, as long as they share the same interest and there's enough overlap in Participation in the different groups that could actually work out pretty well Or not, we all went through the web services so Our stories that for sure we couldn't refer to, you know, that didn't work so well, but I don't I have lots of scars from that um, yeah, well, okay, so and We've noted by make that one for next I'm not sure. It doesn't sound that good though. Um, but uh So, so what do people think are we are we at a point where people have exhausted the q&a and We can move on or do people need a little bit more time to noodle and think about this and discuss it or So there's one thing that I think is important and I was browsing through the document I mean, I see the world standard You know, repeated over and over when in fact there is no standard per se, right? So I understand that's the intent, but uh, we might be a bit more careful Standards be professional might get offended by your overuse of a term. That's not quite right But beyond that, I think what's important is whether, you know, what is what is the dependency? Is the charter basically going to be we're stuck to the spec whatever the spec Is is the gold or does the you know the document Basically say that's the starting point the aim is to keep working in sync with the spec But you know, we are free to diverge if we feel like it And Brian, I think I think the projects need the freedom To be able to make decisions about the spec especially in the as I mentioned on email and kind of the case of a contentious fork And that's one reason to give a name Is independent of an interledger even if everybody knows, you know, just like the Apache web server Everyone it would be an implementation of HTTP, right? Unless things went really really south at the IEP with HTTP And yet the Apache web server developers have the freedom to decide How quickly do they want to implement parts of HTTP? Do they push back on certain things? So You know, you can be a an implementation perhaps even considered one of the reference implementations and not be You know, I feel like you're serving two masters if you will I kind of feel like this project and its maintainers need the autonomy to be able to decide which standards out there They they implement and it may be that there are two standards, you know Implementing the same code base interledger and lightning Makes sense or something like that. Um, at least from as a as the executive director that's been wearing my hat That's how I kind of view it and the fact that there's a lot of overlap between the w3c group and this one Is is fine. Uh, and doesn't mean that the project serves two masters I agree with you Brian and that's what I was trying to get to is I think the document the proposal should make that clear I also quickly want to mention that as ripple We're also not married to interledger if a better protocol comes out or if something else gets more traction We weren't happy to to put our weight behind that We're mostly trying to do this as a way to You know put some effort into trying to design a protocol, but again, we're not married to it Uh, yeah, hopefully we can take a few things to the mail list. Uh, it sounds like we still have some open discussion I in particular would like to hear a little bit more clarity on the maintainer's intent the Document itself talks about hyper ledger project interaction, but it seems most of the discussion has been about um The original premises of payment networks that that are outside of hyper ledger And I don't think either answer is is right or wrong, but I would like to hear a consistent and clear answer on the maintainer's goals Okay, the process record kind of sounds like um, we're not ready to vote this week. Um Uh, not sure if we're ready to have a vote next week given will be at the hack fest at the same time as The usual time for the tsc call So, um, you know, maybe we we should decide offline If we want to have a tsc call during the hack fest and vote on this issue or if we want to delay it by two more weeks It sounds like most people are positive. There's just some some I think adjustments to the proposal folks would be more comfortable with Chris, I don't know if you want to take it from here Yeah, so I was just I think I think that makes sense. I don't know if we're going to have a call or not I mean, we were trying to discourage everybody else from having calls But um Maybe maybe we should I don't I don't know Stefan and and adrian and others. Are you guys planning on attending the hack fest? Not in chicago. No, unfortunately I'm I'm in San Francisco for a short time and then I'm actually basing k-top. I'll be back in k-top soon Okay Well, then Yes, let's Let me take a look at what we have in the agenda Um, it may make sense to have a maybe a half a call Next week, but usually we sleep on stuff such things We do sleep, you know When the proposal is presented normally the we do kind of Let it's you know, people sleep on it a little bit before they would yeah Yeah, we've done that for the most part in almost every case so let's um I mean, let me just I'll I'll think about you know next week and look at the agenda And see if we have time to to fit in a call Brian And but we can also vote via email. So I think does Dan suggest and taking it to the mailing list and and uh potentially updating the The proposal based on the the comments and the feedback and the questions Um that are asked that we're asked today and and and maybe we can be in a place where we can We can vote on it by email or it over a quick call That make sense If so and since we ran out of time Tracy doesn't have to do any more work And I think we'll call it uh call it a week. So thanks everyone. Thank you. Thank you. Thank you