 Hello, shall we start? Thank you all for coming. I really appreciate your presence here, especially because there are three concurrent sessions. So today I'm going to tell you the story about our latest project. Actually, it's going to be the production today. It's done for our clients, HLB International. So they are somehow SharePoint-based organization, and they still wanted to use blockchain as a backbone of their one solution. So while the title, it's a bit tricky. We wanted to also show you that it's possible to combine closed source projects like and paid software like SharePoint, with open source. My name is Domingo Zyskowski. I'm a consulting director in SPL blockchain, and we as a company are one of hyper-certified service providers. So we are a service-based company, and we do projects for clients like HLB who want to adopt blockchain into their ecosystem and into their processes. The agenda is as follows. So I still want to go deeper into the comparison between SharePoint and Fabric. Then we'll tell you more about the business case that we handled within that project. Also show you the architecture of the solution that we built, give a demo, and some final words about what we learned during that project and what can be the next steps in the further development of this solution. So as I told you, Fabric and SharePoint are totally different words. From one side, we have open source project that is maintained and developed by many people around the world. On the other hand, there is a Microsoft-based system that is their proprietary software and it's not open source, you cannot commit as an external person to that code base. Another issue or another fact is that this company Microsoft, they are not that much into the blockchain space. From what I know, they used to be even a member of the Hyperledger Foundation. They had some managed blockchain solutions offered, but last year they resigned from that and that also shows the engagement and the directions that they selected within the technology. SharePoint and Fabric may be about storing the data in the secure and trustworthy way, although they have totally different philosophies behind. So from one side, we have a centralized solution, centrally kept access rights and permissioned roles. On the other hand, Fabric is about trying to provide a decentralized way of accessing the data, still allowing for having different permissions across different users. Data Governments models are also a bit different. In Fabric, we have the parties that somehow allow to determine the access rights of other organizations and users that form the network. In SharePoint, we have centrally managed user management, permissions management, and also the data storage. We encountered a number of solutions to store content, store the data. On the blockchain side, on the Fabric side, the data's transparency, immutability is guaranteed. On the SharePoint side, there might be the attempts to tamper with the data because the person that has a top admin rights is able to overwrite and delete data from that system. At the end of the day, we managed as a company and together with our clients to combine those two words and to take out the best of both solutions in order to build a successful system that caters for the users and allows to follow the business process as it was planned. The business case is about exchanging referrals between the members first of HLB International. HLB is a global network of accounting and advisory companies. They work under umbrella of HLB, but in fact, every country has its own business entity that is independent from one from another. There is totally different invoicing systems, ERP systems, and all the systems that handle the operations of that companies. The only common tool that is used, worldwide is SharePoint, which is a communication platform for them. So the business problem that the client had is to handle the referral process in case that let's say the member company from Ireland wants to refer a client to the member company in Germany. If that lead becomes a client, there should be a free page to the company that refer the client to the receiving member firm. Up till now it was happening through emails or phone calls, or some offline messages, and therefore it was quite cumbersome for the global office of HLB to handle the disputes between the member firms to settle the payments that were due and in fact the team of a few people in the executive office of that company was spending like few weeks every year to handle manual disputes, handle the settlements, and clear the payments between the companies that were involved in the referral process. Of course, there was no single source of and therefore it was quite hard to follow who referred the company to who, and whether that lead was really converted to the client and what were the payments associated and so on. So although the process looks quite simple, because having a referral offered to the company that receives a referral can either reject that or accept, and then they need to contact the client, they need to make a proposal, and the proposal may be successful or not, and after the proposal is successful, the cooperation started with the client, there is some billing, some invoicing, and the company that refer the client should be awarded with some percentage from the total value of the deal. We together with our client wanted to automate and somehow digitalize the process with using the tool that everyone in the company is using, so using the user interface from the SharePoint, but still to have the centralized place in which the data is trustworthy and it's validated and no one can say that the data or the referral was fake or not valid. So we came to the conclusion that fabric, that blockchain technology can be a good solution to that problem. The architecture of the system that we built is simple. We didn't want to build a very complex fabric network, so actually the software that was implemented here can be divided into two logical parts. One part is this backend system that plays a role of a middle well between the SharePoint UI and the fabric network. It's written in Java and listens to the events that come from the SharePoint, events that are related to the change of status of a given referral, and also change of status of a billing that is associated with a particular referral. We have two virtual machines with blockchain nodes. So one fabric node is actually each fabric node is in different region, and the topology of that network is quite simplistic, but that was good enough for the first implementation for HAP because in fact, it's the first blockchain project that they realized, and the first blockchain project that is going to be released to the production and it's happening today. So also I didn't want to mess with the environments and I recorded the demo before the meeting in order not to break anything for my colleagues that are working hard to deploy the software to the production. So the demo is recorded, let me play that. So here basically we have a normal dashboard that HAP users can see. Of course, this is the admin view, which means that we are able to switch users, but normally the users can see only the elements that they are able to see on their boards, and this particular widget can be used to create new referrals and send them to the other company from the HRB group. So here we want to create the referral. We are now the entity from Armenia and we want to refer the client to the Vietnamese branch. We need to specify the data, the details of the person that will receive the referral, also the information about the client, like first name, last name. All this data is stored to the blockchain, to the ledger, and it's also important that we store on the blockchain all the data associated with the referral. It's not a big amount of data, so we decided to store everything. Here we also determined the field of the service, the type of the industry of the client, and we can send the referral. With sending the referral, we also specify the predicted value of the deal. So let's see what happens next. In the Hypergler Explorer, we are able to see whether this transaction gets to the block. For now, it's not there yet, but in a while it should be submitted to the ledger. Here we can see that this particular transaction, this particular referral landed in a block. We can see the details of the transaction. So for now, this new client is handed over and the Vietnamese entity will be able to see it on the dashboard when it gets to the ledger. It's quite important also for the users that they are able to see whether the particular referral already made it to the blockchain. So we also added this type of indicators that show that the particular referral or particular event or billing was added to the ledger. And now we are switching the context to the Vietnamese entity. We see that in the receipt referrals, we see the new one. And now what usually happens is that the discussions with the client may last several months. So all these statuses of the particular referral will be also stored on the blockchain, on the fabric level, in order to see when the particular status was changed and what was happening with that. We need to somehow go faster with that. So we change the statuses from the accepted to contacted. Then the proposals should be sent and if the client accepts that the deal is done and we have a client. So we also need to make sure that all these changes get to the block and it needs to take several seconds to be processed. But finally, we will be also able to see in the Hyperjack Explorer that those statuses were changed and they were added to the ledger. The amount of data added to the chain is quite minimal. It's simple JSON file that gets saved in the chain. But it's also quite important to the user that they may really trust that this data is really stored. It will not be changed and it also increases the amount of trust between the companies. That are still in the same network but they may not have done any business before. So here we can see the list of transactions and you can see that the status was changed to contacted. So another transaction in the ledger is a new status. It's the status proposal. The next one will be hopefully succeed which means that the deal was done and the client restarted the cooperation with that particular company. It should be visible here. Yeah, success. So when the cooperation is started, it's important to add the invoicing and building details to the system because it will be a base for kind of making the payments and settlements between the component that want the deal and the component that refer the client. So with adding every new billing item to the under this particular deal, we need to specify some data like, of course, the amount of the invoice, maybe some comments and simply add it to the system. And that's basically it from the scenario point of view. So all the data, as you can see, the billing row has been added to the system. So when the user logs in next time, she will see that the data was synchronized with a blockchain, with Fabric, and from now on, this data may be used as a way of settlement and way of having the transaction between those two companies. So that was the demo. And what we have learned from this project, so we really wanted to introduce a blockchain as something that's really transparent for the end users. Since this system is going to be used by a few thousand people around the world, we didn't want to kind of introduce something that has very complicated UI. We also wanted to make users use the system that they already know and also show that blockchain layer doesn't have to be something scary. As next steps, there are plans to introduce internal tokens in order to settle the transactions between the receiving and referring companies. It also turned out that it's quite easy to integrate both open source and closed source projects. So that's all. I'd like to take your attention. I also wanted to invite you to the meet up and webinar that will be held on the 28th of September to be about the deployment of hybrid networks through with Kubernetes. Thank you. Yeah, we have two questions. I want to ask a couple of questions on the GTR, because we saw all the data from the blockchain for the project. So in my opinion, every participant of the network can see all the data. And even though if the client is in action, it turns out to be a customer, the data should be removed from the ledger because there is a right to be forgotten in the GTR. So how do you handle this? Yeah, I will repeat that question for those who are online. So the question is about handling GTR within that system. So the regulations that those clients are already there, because the company has clients that they have been working with. And they may refer this particular client to the other entity. And the client's data is not on the blockchain. So only the events related to referrals are stored for now. And there are no plans to handle the right to forget about the client. We might somehow make a workaround by adding only the hash of the client to the ledger and leaving the client's data into the original system. Yeah. Yeah. OK.