 for how I can modify that academic literature line. We've been banned, et cetera. You know, we really, I'll tell you, confluence is becoming more of a pain than its value. And part of it, I think, is just because the cost of a plugin for word import is prohibitive. That's my understanding. You know, the other option would be using just hashes. Okay, I'll just do something text-based then. I want to make the template basic so that it's really easy to upload and update. I think it's gonna be, it's such a critical resource for me. And so I assume it would be for others. And I really don't want you to change the format for the sake of, you know, of the Wiki in this case. So. Yeah, but I can change the template. It seems to make sense. Yeah, anyway. That's all. I did see something from Ravish, and I haven't had a chance to walk through it yet, so. Yeah, okay. Alrighty, well, as folks get on the call, good morning, everyone. Happy Friday morning or afternoon or evening, depending on where you're calling in from. It's great to have you today. And again, we are gonna be hosting a special guest, Walter Montes from KUBU, it's fantastic. So before we get started with that, I do wanna mention that all of our events are being recorded, this included. And so if it turns out that you miss or have to drop off the call, you always have the option to sort of pick it up after the fact. And as we always do, we start with our antitrust policy notice. And so I'm sharing my screen. You should see this antitrust on your screen as well. Feel free to read through it. The upshot is be a good person. Don't cheat or steal, and that's what this is all about. But you can certainly read more into it if you want to. There's a full on antitrust policy link here. Feel free to go through that. Okay, so do we have anyone new on the call this morning who'd like to introduce themselves? Hi, good morning. Good morning, everybody. This is Daniel Schott. Good morning. Because it's recorded. Yeah. I'll say that I'm here on personal interest. I'm working in the healthcare field. And I've always wanted to join one of these calls and learn. And I don't have time to contribute yet, but I'm excited to be on the call and just listen and learn. Oh, very cool. Where are you calling from, Daniel? What area of the country you're from? Fargo, North Dakota. Oh, wow. All right. Excellent. And how are you associated with healthcare? Definitely one of the large data and analytic firms in the nation are global. So, yep. Oh, very cool. Well, glad to have you. Yeah. And I'm sure we'll find a way to get you more involved with some of our subgroups as well. Thank you. Thanks for getting on the call. Thank you. Anyone else? I heard someone else chime in as well. Hey, good morning, everyone. This is Phil. Good morning, Phil. And who are you? I'm joining, representing a pair. We are exploring blockchain and specifically, we came across the convector framework. So excited to learn more about it. Oh, fantastic. This is definitely the call to get on. Yeah, convector. Well, Walter will be talking about convector, but convector is gonna be, what we're perceiving as the replacement for composer. And so we're very excited to have Walter speak to that because we have quite a number of folks who use composer for the sake of fabric stand-ups. And so this is gonna be an interesting, sort of perhaps segue as far as product goes. But I'm not gonna steal Walter's thunder on that. Well, great to have you on the call. Fantastic. Anyone else new to the call? This is Jerome. Like Phil, I'm also part of a big pair. Glad to be on the call. Excellent. I'm a planner. Welcome, Jerome. Oh, I'm sorry, where are you calling from? Atlanta. Atlanta, okay. Outstanding. Well, great to have you as well. Hey, Richard. You're all good. I'm not new to the call, but it's been a while, so just wanted to give you a heads up. Oh, hey, Ken. How are you doing? Glad to have you back on the call. Yeah, we've been crashing, preparing for the collision conference up in Toronto. So I think everything's ready. So good to be back on the call. And yeah, and you just jinxed it. So. You're correct. Now, all the printing orders have been canceled and nothing's going to be there. So it's going to be great. It's going to be great. Fantastic. Good, excellent. Well, great to have folks on the call. New names are fantastic. Yeah, I'm sorry. Go ahead. Awesome. Yeah, we're on over here. So I'm also from Warsaw, I'm actually city of Warsaw. I'm just here to partner with Walter and his talk. Oh, excellent. All right. Great to have you, Diego. Yeah, good. Good to have you on the call as well. We may be able to sort of chime in as Walter goes through his presentation. Fantastic. Okay. All right, so we'll sort of get started. Sort of the next thing that I wanted to make a comment about was we have, we're currently active, some more coming out of Cambridge. They're doing some academic research in the field of blockchain development. And they're looking for folks who have production blockchain solutions already out there. And what they're doing is they're looking to document their second edition of their global blockchain benchmarking study. And this is through Cambridge. This is one of their earlier studies that they put together and they are looking for folks to participate in the study. And so if you're interested, please feel free to contact Michele or Epeline. And these are their email addresses and contact them directly and go to town. And if it turns out that you do participate, it'd be great if you could report back to the Special Interest Group and let us membership know about how things went. Okay, so I'm gonna hand over to Walter. So again, Walter Montes is the CEO of World Cebu. He'll be presenting on some of the tools and technologies as they produce for the sake of blockchain development. Here's their website just to sort of whet your appetite for those that aren't familiar with World Cebu. And Walter, I'm gonna hand over to you and feel free to take over from here. Okay, Rich, thank you. So good morning, everybody, or good afternoon. First of all, I really thank you, Rich, for inviting us. I was in the last meeting in which Instamet was presenting their solution. So I kind of know what the logistics and dynamics of the call are. So I really think this is a great forum to talk. In the last presentation, I really felt welcome and I think, Rich, you are doing a great job to create this great move around these calls. So yeah, really, I really appreciate the opportunity to talk to the group. I will be sharing my screen, so let me just try in here. There you go. So if you could let me know if you are seeing my screen. Perfect, and we see lots of code. Yeah, we will be going through some code. All right, go for it. Yeah, thank you. So well, first of all, World Cebu, we are a company dedicated to creating enterprise tools for blocking. We have been in this for a few years and we have gone through work in consultancy to products. So the reason why we built what we have built so far in this group of tools, there is convector as well. It was because we needed it. So that's usually the logistics in how we work. We need something that we believe that other people need and then we throw it as a product. So as Rich was saying, convector, which is the main topic of discussion, you know, these have been positioning itself as a new tool to help the people that composer were left behind. So I will walk you through this with a healthcare example. Though I have to tell you that we are not healthcare experts and our mother tongue is not English. So I will be translating from Spanish to English and to healthcare language, which we are not experts on. So I appreciate your patience. And if anything is not clear, just let us know. So yes, just a little bit to tell you because the use case that I'm going to show you is based in Costa Rica. So just to tell you a little bit about the country, in case you don't know us, we are in the middle of America. We connect South America with North America. If you have been around on vacations or something like this, you know who we are pretty much. We have this tech hub in here in which a lot of different big companies like Intel, IBM and so on are working here. And we also have great vacation places. So in case you want to visit us, we have all that is needed, just like high tech and nature. So you're welcome to come in here. So to understand better the use case that I'm going to show you, which is a redacted version of the actual project that is going on. I tried to pull out some pieces of code that are not confidential. I need to tell you about the context of the use case because we have some special things going on in here and this affect the design of the use case. So pretty quickly Costa Rica's government, in the government is focusing on digital transformation, following examples of Estonia, Belgium, Singapore and so on. Right now there is a big focus on interoperability. So there are a lot of examples and scenarios such as the one that I'm going to show you. The idea is to connect the government between governmental institutions and also with private organizations, which is right now pretty much based on paper. We have a country-wide digital signature. So we have the central bank issuing certificates through their central certificate authority. So pretty much any person in Costa Rica can digitally sign anything and it has legal validity. So it can be used for a lot of different processes and it's being in production for a few years already. So this is important because as you know, Fabric has these certificate authority structures and PKI's, but we need to merge this with Costa Rican certificate authorities. We're small, we are only five million people. Actually a few months ago, the five million person was born and we have one of the best public healthcare systems in the world, which is weird for Central America and it's covering a big amount of the population. So even though we do have private healthcare companies and institutions, the public is the default for people. So as I was telling you, so to tell you a little bit about us and where we are going to focus, this is what we have built. These are our tools. We will be focusing on this conversation on convector, but convector is part of something bigger that is called the convector suite. So the convector suite has convector and Hurley, which are both open source and based on GitHub projects. The convector framework is for development. So it is in which we are going to focus. It was initially developed internally based on our experience with Golan smart contracts and JavaScript smart contracts, as well with HyperNear Composer and Hurley is a development environment. So it's pretty much one line to create a blockchain network in your computer. We also have obviously in our business side, which we have two main tools. We have Telus, which is a tool for business people to design transactions. So we usually use these as a means for validation of use cases. So for example, if you are thinking on validating a business hypothesis, you don't want to develop everything from scratch. So Telus is a web interface in which you drag and drop and you end up with a smart contract. But that's not the focus of the conversation. And then we have our main platform, which is FORMA. FORMA, it's an infrastructure orchestrator. It's to create development and production cloud environments. It's multi-cloud and it is remote. Even though we are focused right now mostly in HyperNear fabric, you may already know that every blockchain framework has its own group of special things. You have to go really deep to get into a really nice spot in terms of expertise. So we are right now focused on HyperNear fabric, but convector itself as well, FORMA and Telus are meant to be migrated to HyperNear software, core room and other blockchain technologies. So this is important because as I will show you the design of convector specifically is made to run in multiple platforms. And right now you can already run convector in the browser as well as you can run it in the server as well as you can run it in the chain code. So this is a quick explanation on what we do from the business perspective so that we get to know each other. We have this infrastructure orchestrator which is called FORMA that I was telling you about. It is basically a way to do something similar as blockchain as a service, but in a decentralized way. So what we do is the tool allows you to pick your infrastructure, whether it is Amazon, Microsoft, Google, but in your own account, we don't keep the infrastructure, we don't have the data, and the tool connects to you and it installs everything. So for example, there could be a network made of Amazon web services and Microsoft Azure and Google Cloud infrastructure all together working coordinately to create a blockchain network in which we never keep the infrastructure. So there are innovations with Amazon, Microsoft, Google, IBM, digital oceans and native communities. It looks kind of like this. It's just trickleaks and you create a network. So it's not dependent on convector, but it's just to get to know each other as I was telling you. So let's get to it. Let's talk about the convector suite. So a few years ago, when we started as a company, we were focused on consultancy. So we engaged with consortiums and companies that wanted to create enterprise blockchain solutions. And at the time, the only options out there were HyperDare Composer and Native Fabric with Goland. So we developed a lot of things in Goland. We were not experts. We had to go through the learning curve. You may already know Goland as a programming language for Fabric. It's not that easy because when you are working for a blockchain technology, you want to be sure of everything you are doing due to security obvious reasons. We never felt that safe about what we were doing, but we didn't like Composer's approach. Composer was a great tool for prototyping, but it's architecture. It's, I think, the reason why they are kind of deprecating it or at least people are not sure about the feature of the tool. So as soon as Fabric added support to Node.js, we migrated everything from Goland to JavaScript. So in the team, we have people that have worked with some of the biggest web portals in the world. So we have a lot of knowledge in JavaScript. We know how patterns can be leveraged to build better software in a more scalable way, in a maintainable way. So we took that knowledge in JavaScript and we put it to work to create Convector. So at first it was a closed source framework, sorry. We developed this for our customers. We started creating solutions pretty quickly and in a much more safe way than with Goland previously because we had the expertise. And so when we moved from consultancy to products, we is a format which our focus pretty quickly as people think that this is better than blockchain as a service. It's usually when people don't believe in the as a service part in blockchain. You know, we don't believe in that as well. So we decided to take the code and release this as an open source project. And in a few months it had, it started to have a lot of downloads, thousands of downloads without much marketing. And it was because people wanted a predictable way to build smart contract systems in HyperLayer Fabric. So we started talking with the Linux Foundation team specifically in the HyperLayer project. And they told us that it would be a good idea to contribute the source code to the HyperLayer Labs to see if this could eventually become an official HyperLayer project. So we did, we submitted the code and it has been in there for a few months already. So in general, after we created Convector, we knew that people were struggling to set up development environments. So it usually took, you know, a few hours to get to know the script and all these details that really never added value. So we created Harley as the development environment. So it pretty much allows you with just one line to create a development network that you can use for Convector or for anything else. And that is important. Harley is completely decoupled and every tool that we built like Forma is decoupled from the others. That is part of what we believe that is key for interoperability and for a health group of open source and closed source tools. So Convector in general is a development framework. It's people compare Convector to Angular for blockchain. If you are from the web development or you have some knowledge in web development, Angular is one of the most famous and used development frameworks for frontend. So they compare it to that. It is based on a known pattern, which is the NBC pattern. It's developed on TypeScript as well. So it's important that it is developed in TypeScript because of the roadmap to migrate this to other platforms. Convector's target is clear. It is for developers. It is not for business people. Sometimes a composer used to say that they were for business people as well for developers. Convector is purely for developers. It is for enterprise development and I will tell you a little bit about its features and it has its own command line interface as well to bootstrap projects and so on. So taking consideration that this was right after Node.js was supported in fabric, so there wasn't that much options. Right now we have Java, which looks a little bit like Convector and the tools around JavaScript and TypeScript, the native tools for fabric are getting a much more familiar face for developers, but at the time we only had golden, right? And we had JavaScript and that was it. And curly is this development environment. It resolves all the dependencies in your computer and it's just one command to network and it has an immutable setup. So the idea behind this is that a good practice when creating these development tools is that when you have an environment, it has to be immutable, meaning that you only can create it or destroy it completely. You cannot modify it because you will end up with dependencies and orphan components around that you don't really want when you are developing. And it is the couple from Convector. So just a little bit about Convector, which is again the main topic and I will show you a healthcare example using Convector. It is an actual development platform. It is not for proof of concepts. It's certainly used in proof of concepts sometime, but you can take the same code and take it to production. It is based in TypeScript, therefore there is compilation and you can detect errors. That is something that you want. You know JavaScript, as I was telling you our main expertise before blockchain was JavaScript and working with huge web platforms and forums out there. JavaScript is great. It is really flexible, but it is really easy to do bad things or poorly designed things in JavaScript. And there is a reason why in the front end, we have Angular and we have React and we have View and we have all these tools. And we thought about having JavaScript on blockchain. So it's full stack so you can use the same code that you develop in the chain code. You can take these libraries and you can import them to your backend. We have already implemented this with Nest, with Express and you can also take them to Angular and react in the front end. This is important because it is critical to be able to reduce as much risks as you can during the development of your platform. So if you can reuse the models or the designs of the smart contracts, the functions and things like that, it is great because it really uses servers. It is based on models and controllers. As I was telling you, it is a common pattern. Everybody develops in model view controller or model view model and all of these patterns. So you can focus on business and you can abstract complex modeling into code. It's enterprise ready, so you can do unit testing, you can do continuous integration, continuous delivery with it and you can do debugging and all of these common things. Then again, these were not that common when convector started sometimes and right now you probably have some of these features in other tools out there for fabric as well, but convector has been maturing for these months. It is modular so you can create units of logic that you can then bundle up to convert them into a single smart contract that is better for code scaling. So even though you end up with just one smart contract when you are developing, you want to have things decoupled so that you can do things like having things work in just some pieces of the code and you want to test things separately and so on. So it is better for scaling. It also works with the native fabric features and this is key. So everything that you can do with native fabric, you can do with convector and that is because we took an approach that is called peer dependencies. So convector works by itself and fabric is a dependency inside of convector. So if something changes in fabric, it doesn't affect convector and if you want to access something that is in fabric, you can go through convector and access the native features. So you are not limited to just what convector supports and it has helpers to allow for an explicit predictable behavior and that is critical because again, JavaScript is not that. JavaScript is unpredictable, it is hard to track but when you add TypeScript, it starts to make things better but we created a lot of helpers to make this code much more predictable. So it looks like this. In general, you have models and you have controllers. So the reason I believe that so many developers are migrating from composer to convector is because it has also this great business conceptualization that composer had. Composer was really great for designing, right? Because if you use it, you already know that you can do things and you can create these concepts that make two things from the real world and brought them to the blockchain. In convector, we have models which are these classes that they depend, they extend the convector model type in which you can have these properties and you can have complex properties nested. So it's really enterprise-ish kind of code but you also have these helpers, these helpers that look like what you already have in Java right now for public as well. These helpers help you create this predictable design in the components. So what happens in here is that I'm telling this model, this asset has these properties and they are decorated with these functions. So for example, if you want a property to be required, you could do a lot of if statements to check if the, you know, if the code is validating these things or you can just decorate the property and automatically this will generate the code for you to validate that this is required. As well, data types and things like that, the convector makes sure to force these things. So if you have work in low level with fabric, fabric send things in a registry, so you have to somehow guess the types and convert things and things like that, you know, a lot of low level things, models do that automatically and they also have these great helpers which have a lot of features that I will show you in the code and the controllers are the actual functions inside of the smart contract. So you could have multiple controllers separated based on business and logic units. So it looks like this. So as you can see, these are really small funds. You can do simply receive a model and do that safe and that's it. You know, if you have work in Goldland, you will be surprised by this or in pure JavaScript. Everything is abstracted for you so you can simply receive this data type. If this inherits from a convector model, you can just do that safe and you don't have to throw 10 lines of code to make a safe or to make a modification. So validations become more a business thing like this, like what developers are used to and it looks like an ORM kind of, you know? It looks like you are somehow designing your database with this. All right, so I brought this in case people have questions about how convector looks like versus composer, but I won't get into details of this. So why you should use convector? Convector is built to run in multiple platforms, not only blockchain technologies, but multiple platforms like the browser, for example. So basically the code that you create is in TypeScript. It gets its own ASD with these abstract syntax tree it is a way to take the code and convert it into a portable format. So from the ASD, this gets compiled to JavaScript and in this case, it goes to Hyperlegia fabric and it runs natively. That is important, it runs always natively. You don't need extra components like containers or things like that. So our design is based on the idea that this ASD can be taken and be compiled to WebAssembly, to Solidity, to Roland or to anything else that we want to. It may take some work to migrate these completely because of the dependencies to WebAssembly or Solidity, but convector has this design based on what we call adapters, which adapters are these decouple components that bring platform-specific things. So for example, you design your models and your controllers and you create a specific adapters for the platform. So you could have an adapter for MongoDB as well you could have an adapter for fabric as well you could have an adapter for Solidity or for, well actually for Quorum or for Ethereum or for Hyperlegia software and so on. This is key because a lot of people used to ask us when we started with convector, how is this different from Composer? Composer also had the idea to be a multi-blockchain platform, but they didn't achieve this completely. How are you different? This is one of the main reasons. It is a decouple architecture. So we will go to the code to show you and I will explain you pretty quickly the use case, but our overall goal as a company in open source and in business models, as we are not experts in industries, we team up with companies a lot. All the work that we do, we do it with partners. We never execute a project alone because we don't do consultancy. So we let other companies make that money or sell other services. But our overall goal is to make blockchain so accessible that less transformational projects can benefit from the technology. And our hypothesis is that what is happening with blockchain is the same that happened with databases once. Databases were so expensive to implement to set up the servers and so on that it didn't replace paper-based processes immediately, it took some time. It took a lot of tooling and core components to be able to solve less transformational use cases. And right now, you see all these big companies creating these transformational use cases for their food industry and the Marisi logistics and the financial industries. But we believe that blockchain is an integration layer with an estate matching. And that is all that we see in blockchain. The use cases are really transformational, all you want to say. But in order for blockchain to be widespread use, it needs to be as cheap and as easy to implement that less of transformational projects can be implemented. I believe we have a comment or something. Yeah, I think we can review them at the end because I don't know if I can see them while I'm sharing my screen. So yeah, let's talk about the use case to show you the code. This is in Costa Rica, a public and private sector interoperative roadmap of solutions in the healthcare and other industries. So the first thing, it has four stages. I cannot talk a lot about the details, specific details, but I can talk about the... First is to make evident the data sharing between parties. So you have private companies, you have public institutions and we need to make evident that me as the patient are approving the laboratory one to access data from the public sector, for example. The second stage of the project is going to be to create privacy preserving features. The third one is to bring EMRs interoperability into the blockchain and the fourth one is to have the user control their own data. So we are exploring projects like ARIES and INDI to be able to give the consumer, the patient, control over their electronic medical records. So the first phase, which is the code that I brought, it's a peer-to-peer request to access patient data network. So pretty much we have the government, which is this one that is called CCSS. It's Cajacos de Recensa de Seguro Social, which is our public healthcare system. They have this system that is called EDUS. It is the electronic medical record of the government. It's just one because we are really small and we can do things like this. It's benefit that Costa Rica has. So the idea is that the government communicates with laboratories. The government doesn't have all the tools that they need to perform all the exams that they need. Some specific exams like for Chikungunya or Zika or diseases like that. It really needs third parties, private third parties. So laboratories, hospitals, private hospitals and clinics need to share information. So basically for this first phase, everybody will keep their own ledgers, their own databases, and when they communicate with each other, we need to make this evident in the blockchain. So just to outline the case, we have requesters, we have approvers. We have patients that are signing and approving requests. So for example, me as a patient, I need to digitally sign approving that this laboratory will access my data in the public sector and the other way around. So we need a proof trail of patient approved data as I was telling you. So the thing here is why blockchain, right? We usually make these hard questions like why do you need blockchain at all? The thing is we need digital signatures, we need encryption, we need trails of data. So without blockchain, we have some unanswered questions which are the ones that are in here. So these unanswered questions are things that we believe that blockchain can solve or BLTs, whatever you want to call them. So pretty much it is based on when is all the data going to be unified if this is separated in multiple silos? What is the time to get the data? How can a customer make sure that all their requests, their peer-to-peer requests of data between all these institutions actually are in a single place that they can control, that they can verify through their signatures. And there's also the need for third party revisions like auditors. So if the auditor is going to connect to every API out there to gather the data, to transform the format from one database to their own database, extract something that is in SQL server and other thing that is in Oracle and so on that is going to get into a really unnecessary spot and unnecessary complexity. And the other option was, well, what if the government keeps everything for everybody? And obviously that is not the answer for this case. So that is the reason why we, and actually the company that is doing this with our tools decided to try blotching. So basically the flow looks like this. The patient make requests. It goes, let's say that the government wants to access data in a laboratory or the other way around. So the patient signs the request with their Costa Rican digital signature. The government makes the request in the ledger. The ledger has the public keys of patients. So it can verify that this was actually signed by the patient and that this data actually is an actual request, an actual valid request. This gets locked into the chain. And then once this is ready, the verification is ready, then the government makes an API call to the laboratory. The laboratory checks the token and then when they check that the token is valid, basically the token is created when they make this request and the request is valid. This is automatically verified with the signature of the public key of the patient. And so then if everything is right with the temporary token that was created, it's telling the government you have access to data in the laboratory. Then when they want to respond the data, they need to lock a hash of the data that was shared with them in the ledger. So at the end you have the proof of approved requests, access request, you have the proof of data access request and then you have the proof of shared data. So you have all the trail and the patient can know that the government was accessing their data somewhere because of something that they approved, as well when laboratories share data with clinics and all of these peer to peer communications. There is just another reason why blockchain made sense in here and the reason is because we have the sponsors on board. So to try to blockchain can solve these issues and these challenges. We usually refer to big sponsors as industry checkers. We call them industry checkers because these are parties that usually can be identifiable in an industry that bring everybody together. And we also, through our tools, we have the technology to make this a low cost experiment. It's not going to take hundreds of thousands of dollars. It's going to take a few bucks to make this test. And obviously we have also the technology to make this scalable. So I'm going to show you the code. We have just like five minutes so that we can leave the space for questions. As I understand the dynamics of these meetings, I was talking a little bit too much so I already talked for 10 minutes. But I'm going to show you a non-confidential piece of code for this project that is made in Convector. We have some participants like the Paso-Rican healthcare institution. We have laboratories, we have clinics. These are participants. We have assets and we have transactions. In assets we have identities of the participants. We have a patient's directory with the public keys. We have the request and we have the access token which locks the proof of the data that was shared. And in transactions we have the registered patients and we have the create request and close the token, you know, use the token. So here is the code. Sorry, there you go. So here is the code. How Convector looks like is that if you want to start a project, you just have to go to a console and you can do coms new and then you set up the name of the project, let's say SIG for this example. And then you define the name of the controller that you want to create. The controller is where you have your logic and we can put in here SIG test and you click enter and it creates everything for you. It creates all the files that you need. So at the end you end up with a folder that looks like this. This is obviously a one that it's already worked. So in here, what you have this code structure, Convector supports native fabric features like indexes, private data, events, things like that, all is supported. In this case, you conceptualize your code in controllers and in models. And this is important again because we need the code to be predictable and to represent the business needs. So in this code, we have these controllers as well we have models. So how does a model looks like? A model looks like this. This is a common class. If you are a developer, you know that this is familiar code that you do every day. We have these properties and we have these decorators. So decorators and these properties can use common things like enumerables. Enumerables are these structures that usually make the code much more predictable because you can limit options and you can instead of using text-based indexes for some states and things like that, you can do them through type classes. So if you make a mistake, this will throw an error on compilation and not in execution. You don't want to spot errors on execution that you could have cut in compilation time. So these decorators can be really simple like saying that a property is required. So for example, in this model that is the request, you can say if data types or if things are with only your things like that, but you can do much more complex things like these validations. This is a library, a JavaScript library. This is not ours. So the idea is that with a convector, you can still take advantage of the libraries out there. So we use jupe, which is a validator. So you can do complex things like saying, okay, the data proof of sharing data will be required just only in the scenario in which the status of the token is used. So if you try to mark the token as used, you have to include a data proof. Otherwise, you don't need them. Why is this important? It is because when you get something in a controller, let's say that you have this function, you receive this model, right? Well, let me show you one. You receive this model. It's pretty much from the outside, you are getting this model. If the validation is not met, you don't even get to execute the code. So again, it makes the code much more predictable and much more safe in execution. So if, for example, in the request, I am saying that this field is required and then the request is not standing it won't even enter here. Convectories, catchy, those things for you. And then the code looks like this. Again, you have access to the whole fabric API. If you do this.txt.stop, that you have everything for fabric that you need. If you are going to code for Quorum or for Softfoot, you can just import instead of this chain code TX, which is a fabric-specific type. You could in here put something like Quorum TX and then you can access Quorum native functionalities. So basically, again, you can do things like that safe and that's all that you need. Okay, so this is the code example. Something else that I want to show you is how you do unit testing, which is critical. Unit testing is a mandatory part of Convector. You can obviously always go without unit testing, but all the good design patterns and development patterns recommend that you do unit testing. So in this case, you can create mock things. You can do unit testing just as you would regularly do. So you can go to your console and you can do something like NPMT and it's going to run the tests for you. It is basically compiling the code and it is running this unit test so that I know that if somebody made a change to the code, they won't break things. So as you can see here are all, this is emulating the blockchain and that's it, that simply you can do unit testing. So you could take this, this unit testing does not require blockchain, right? This is just logic testing. So you can include this in your own continuous integration or continuous delivery pipeline. So when you are pushing code to the repo, you can verify that everything still works and again, you are creating much more maintainable code base. And at the end, if you want to run this in a blockchain, you can do NPM Start and NPM Start is going to do a few things. It's going to call Hurly. If you remember that I was talking about Hurly a little while ago, Hurly in here runs this command Hurly new and just that is going to create a whole blockchain network in your computer. And that's it, you don't need to do anything else. And then you can run Hurly again to install a smart contract. So you can do, in this case, Hurly install the name of the smart contract, the language that you are using and the folder where you have your code, which again, Convector compiles to native JavaScript code that you can modify if you want. This is the actual code that is going to run in the fabric containers. So Hurly, what it is doing in here, it is installing all the blockchain in my computer and I can just run this and start working easily. I went over the time that I was assigned. So I think we can move to questions right now. Excellent. Well, thank you, Walter. That was really fantastic. Yeah, it would be great. Let's open this up to questions. Anyone? Well, it's awful. There we go. Go for it, Ken. Yeah, thanks. I was wondering that, I mean, you walk through a lot of functionality. It looks great. I love the streamlined aspect of the IDE and the fact that it incorporates Hurly as simply a reference call. How many, do you have account on how many actual implementations or how many builds are actually being deployed in production environments that are leveraging your tool? Because under your open source, so maybe you don't have account, maybe you do. I just wondered if you had any sort of idea of the production footprint out there for code that's being built using your tool. Yeah, at first we didn't have data, but we started to create these indicators to see if we are doing things correctly. You know, if we are building the right features and so on. So in terms of downloads for some months, Convector represents 10% of the total JavaScript downloads for Hyperlink Fabric. So it has widespread use but to your questions about deployment, we know about a few tens of projects. We know of like 25 projects that are actually going to hit production eventually, that are being developed with Convector. We don't have much statistics, as you know, we try to ask people, but not all the time they want to answer. Obviously. Yeah, and we also have statistics based on geography. So we do know that Convector is really used in the United States, India, and some parts of Europe. Through the CLI, we have to feed people to anonymity, collect some data. So we have statistics about that and we know also from the statistics perspective that 80% of the people that use the common line interface are unique users. So that means that usually the common line interface use this the first time. You don't have to recreate your project all the time. So 20% of the people are creating new projects and 80% of the 45,000 downloads are creating new projects. So that is kind of the data that I can talk about this. And we obviously ourselves have implemented this in production as well. Obviously we implemented this in production before it was open source, but yeah, we were the first ones. All right, thank you. Sure, thank you for the question. Good question, anybody else? Hello, this is Jonathan. Any issues converting from the JavaScript to Golang, especially with large ints and formatting for like slices in Golang? Yeah, actually the reason why this is the compilation to other languages is not generally available is because usually the code it has some native dependencies that need to be worked out. So the main issue is not on the convector code. It is actually on the dependencies like the fabric libraries that have some specific things and some specific implementations. So there have been some experiments in the ASD compilation, but it is not completely done. So yeah, it has some issues that need to be worked and we invite everybody that wants to contribute to the code to help to make that migration. So yeah, it is not fully worked out yet because of these dependencies. So pull requests are welcome. Yeah, absolutely. Another good question, anybody else? Do convector support chain code events which comes as part of fabric? Yes, absolutely. We are actually going to improve events in fabric. Events are based on this unique response and you have to put a lot of things in there. You cannot have like a smaller events emitted from the blockchain. So it supports the native event framework in the front end. Sorry, in the backend and also in the chain code, but we are about to release an improvement to segment events specifically. So you can do things like I'm going in this transaction to emit 13 events separately. So instead of putting everything together into a single event, convector is going to improve that to create name spaces and things like that for that. So the answer is yes, it supports them and we have projects that are going to production ourselves that are using events from fabric. That is awesome. Just another question, these in invocable methods that you explained as in the controllers, these invocable methods cannot call each other though, right? Yeah, they can. When they are in controllers, you can, controllers at the end are in the same smart contract so you can call them between each other and you can also do calls to another channel with another smart contract installed. You know, cross-channel communications is available in convector as well. How do those... How is a visibility being made across channels like within the code? Is there a documentation that I can look up for that? If you can... Yeah, sure. Sure, we use the same fabric features in there. So it's the same rules that fabric applies so the node needs to have access to both channels and the endorsement policies need to match and so on. It is the native feature that we have in fabric. Convector makes it easier, not only, but it's the same logic. Actually, just to give you a little bit more information on that one, so what I was having to say, but we have a show every Friday, actually we're going to record a show today in the afternoon, which is Convector Developer Office Hours and in our last episode of Convector Developer Office Hours, we talked about the events and interchangeable communication. So if you want, you can go to YouTube and look for a channel and you pick up our radius event and you will see all the information about the events and cross-channel communication in that one. Yeah, sorry, Rich, I think I took control away from you. I didn't notice. I wanted to share these links, which is where Convector is. So if you want to see all of these are in docs.world.co.com-convector. In here in code samples, we have code samples for private data, for debugging and testing and so on. And we also have the Discord. We manage the community in Discord. There are 250 developers, something like that. And as Diego was saying, we also hold this Convector Developer Office Hours. So every Friday at 6 p.m. CST, we meet and we talk about features and answer questions and things like that. We like to keep the community really active. So if you want to contribute and join the Discord, please be my guest and join us. Thank you so much. Sure, welcome. Yeah, another great question. Well, we are getting to the top of the hour. Maybe one last question if anyone has it. Okay, well, again, thank you, Walter, an amazing presentation and I just want to ask, will you be able to generate a slide deck and I'd be happy to post that up to our Wiki if it's available? So that would be outstanding if we can do that. Absolutely. Well, good. Let's see, anyone else as far as questions go? Alrighty, so the last comment that I'll make is our next HC-SIG meeting is in two weeks. We have these meetings every other Friday. So we're gonna be looking at the end of the month and I believe we are gonna have a regular general meeting. We don't have any speakers, any guest speakers. So we'll be looking at what we're doing within the Special Interest Group and we'll be focusing again on our subgroups. Again, for those of you that are new, we have three separate subgroups where we focus that they're really smaller teams of people with specific interests in the payer space, the patient space and then in healthcare interoperability specifically, which we're spinning that subgroup is brand new. And so those three areas are sort of areas where we tend to focus efforts and that's where projects sort of get generated out of. So feel free to come back in two weeks and again, thank you Walter for your presentation, outstanding and if no one else has any questions, we'll adjourn and have a great weekend. Yeah, sure Rich, I really appreciate the opportunity to join you and welcoming us even though we are not from the healthcare specific industry. And again, we welcome you to join the project. It's CC completely open source and we welcome PRs every time. Outstanding, excellent. All right, well, thanks everyone. Have a great weekend. Bye bye. Thank you, wonderful presentation. Thank you.