Blockchain Innovators - Conor Svensson and Peter Broadhurst

Hi, it's Conor Svensson here, founder and CEO of  Web3 Labs. This is a conversation I had with Peter   Broadhurst. Peter is the co-founder and head of  engineering at Kaleido. Kaleido is a full stack   enterprise Blockchain as a Service platform.  Previously, Peter worked for IBM for 18 years   where he worked on cloud computing and  middleware technologies. In our conversation,   we discussed the problems that blockchain solves  that middleware couldn't and where he sees the   big opportunities for blockchain in enterprise.  We also cover the newly launched FireFly project   which Peter is very involved in. FireFly provides  a multi-party system for enterprise data flows   which lets developers build decentralized  enterprise grade applications on blockchain   based business networks. Like myself, Peter is a  technologist at heart and it was fun to geek out   on how blockchain fits into the broader technology  landscape. Peter, great to have you here. Hi   Conor, great to be here. So, you've been involved  in blockchain as one of the co-founders at Kaleido   for a number of years but prior to that you  were at IBM for 18 years, if I have that right?   And from what I understand, you were  working on cloud computing and middleware,   so I'd love to hear about really what  you did at IBM and how that ultimately   transitioned into blockchain technology. Yes,  I guess it's interesting for me because when   you look at the technologies that I was  working on throughout my career, there's a   huge overlap with what blockchain is trying to  achieve particularly in the enterprise space.   I started at the beginning of my career working on  a technology called MQ/ MQSeries it was, in IBM.   It was one of the original sort of game-changing  technologies for how different companies could   do cross-organization transaction processing and  it was just a messaging system fundamentally but   it was reliable so you could send something  and know it was going to get there.   It sparked a huge, huge wave of these  technologies that were about a different   way to communicate. We've all heard of AMQP and  RabbitMQ and these other technologies as well.   So that's why I started and it's amazing how  similar that is to sort of where I'm back to   now in the blockchain space trying to solve a  similar problem. As I went through my career,   I got very involved in the application service  stack and the transaction processing there,   the websphere stack and also  on the integration side. How   the core systems of enterprise could integrate  together and I did a lot of my my time actually in   the support side, working on other people's  code rather than actually new development. So I   got to see the whole stack inside and out, which  was a really nice journey to be on. And a lot of   work with customers in the last few years at  IBM actually traveling, working with customers   sticky projects, complicated things that need to  be designed, actually being out there seeing the   kinds of business problems that people are trying  to solve with these integration technologies   between organizations. So you say about  the similarities with blockchain and   there's been that argument historically with  middleware technologies - how they can be used in   an enterprise and they could potentially span  multiple business units but there's a point where   it makes sense for a large organization to be  working with middleware technologies. Then there's   a point where potentially they could actually want  to look at blockchain even for actually connecting   multiple subsidiaries of a single organization  without thinking about the external connectivity.   Is there a point there where you feel  the natural jump becomes the blockchain? Yeah, absolutely. Blockchain does  something that was impossible,   throughout my career, was absolutely  impossible. Every previous generation of   how organizations work together before the,  we tend to refer to it now as a multi-party   system, there's this new thing enabled by by  blockchain tech. Every previous generation was   'I have my source of truth. You have your source  of truth. And we're doing some kind of ping pong   exchange. Whether it's SOAP web services or  REST or messaging, we aren't agreed on a source   of truth. We're exchanging information from  two different sources of truth.' And suddenly   with blockchain, if you build a multi-party  system that's got a blockchain in the middle   there, it's game changing because you can have a  shared source of truth with other organizations   and you don't have to trust them to trust the  source of truth. That means that a network of   businesses which are cooperating and competing,  this sort of competition can work together   and have certain agreed truths such as sequences  of events or in tokens, total conservation of   value or uniqueness of one particular reference  ID in the world that we're all using for the   same thing. Those base constructs completely  change the kinds of problems that you can solve   and get away from, we used to call it compensation  logic, it's so complicated. Like, 'I said this   to you, you said that to me, it all happened at  the same time, we end up with different results,   how do we sort out the mess?' And sorting out that  mess with people involved in business processes   could have taken weeks in the past in real  world scenarios. And with the multiparty system,   if you can get it right and you can get the  balance, the right things to be the shared data   and you still get the privacy side of it right,  then you can take those sort of weeks and just   have agreements immediately. Agreements that no  one would bother to challenge because there's an   audit record that's just so clear. But, you don't  have the sort of 'Where's my message problem' of   'Did I say that first?' 'Did you say that  first?' 'I think I said it, but you didn't   confirm that.' 'Does that mean you didn't?' All of  that goes away with blockchain which is fantastic.   Is this something that you recognized when you  were still working at IBM or is it more something   that you've developed a real narrative around  as you've spoken more and more with customers   working with blockchain technology? That's a  great question. Blockchain was the exciting   new thing that was happening in enterprise  for a few years while I was still at IBM.   So it would be the water cooler conversation,  right? It would be with the person who's just   gone to the blockchain team to build blockchain  stuff because it's fun and new and interesting.   So I think that excitement was certainly there for  me, that the possibility it just seemed to me like   this was the first technology that could change  the core of businesses rather than the outside.   It could actually change the way business  core transactions happen. It wasn't just   about surrounding and connecting stuff. It was  actually about changing the core way an end-to-end   business transaction happens and that means for  enterprise IT, it's huge! The potential, still   nascent honestly, potential for cross-industry  revolution on how business gets done. I think   it's a unique technology from that perspective.  So yeah, that was why it was so exciting to   launch into Kaleido, out of that because it just  felt like this could really change things in a   meaningful way. And really make things better as  well because, another side of blockchain is that   it increases the transparency. It can increase  the trust that users of systems can have in the   systems themselves but organizations start to  work together in new and interesting ways which   are more open, more collaborative. They're  building business ecosystems rather than   completely centering in one business and that's  really exciting for lots of different reasons.   Not just what it can do for the big enterprises  themselves but actually what it can do for us all   in terms of systems working better for people.  That's something I think about it in terms of   businesses almost turn themselves inside out when  they're engaging, making use of the DLT because   although there is of course  privacy considerations,   you're not making available sensitive information,  but it's like how the processes can actually run   in that sort of collaborative environment there.  Do you think about there being parallels though   with projects like the Baseline Protocol  for instance? They talk about this notion of   blockchain can almost be used like a middleware  technology between these different organizations.   The fact that you've got this kind of layer of  programmability that can happen at the protocol   layer is one of the distinguishing features  with blockchain, but do you think there are   parallels in that regard as well? Well, yes.  I guess we've been on the journey throughout   Kaleido the last few years, seeing how real  projects get to production on blockchain. The   cold hard reality is, it is a lot like middleware  because these organizations aren't immediately   going to be throwing away all of the core systems  that exist inside of those businesses. So the   only way that a blockchain ecosystem can be valued  to a business is if it integrates with the core   systems that they use on a day-to-day basis.  It's got to make their business better   in a meaningful way and if it doesn't integrate  then it's a real problem. What we've actually seen   is that there's two things that matter, matter  hugely when you're going about one of these   projects. The first is getting the use case right  so that you can demonstrate real value that is   valuable to the players in the system. The second  is being able to take the skills that exist across   those organizations, rather than just the skill  that exists in some central specialist team   that understands blockchain protocols and zero  knowledge proofs and baseline and all of these   low-level technologies, you need to be able  to engage the actual integration teams,   the data engineers, the application builders, and  you need to be able to... and this is the really   key point... get to a proof of value quickly  because I think the fact that it is a lot like   middleware, it doesn't do anything on its own. The  thing about middleware that's been true throughout   my career, you're working on the plumbing, the bit  that doesn't deliver any value in its own right.   It's hugely valuable, but on its own it doesn't  generate the value. It's a tool that allows   use cases to be built on top of it. So, what's the  most important thing about a piece of middleware?   How quickly it enables developers, and for  blockchain ecosystems and developers, to build   solutions. That's the most important value that  it has. How sophisticated and clever it is inside,   is really useful and the subtle differences  between the blockchain technologies, the   different ways that you can use  them, that's great. But really   what do business ecosystems need? They need  proven patterns that have worked elsewhere   just made available to them sort of as middleware,  so they can build applications on top. We've been   astonished looking over the last few years and  coming to projects that have been going a while   and that we've been helping with and building  projects from scratch, just how much rebuild of   the plumbing is kind of the norm in projects.  We try desperately to avoid it, right?   That's just not where the value is coming out of.  So, you need to build on top of it. But we've seen   incredible amounts of resource being used  on just building the plumbing necessary   to have a blockchain network  with everyone having the nodes,   have the transaction streaming on, have the  events coming off, have the private data   integrated with the blockchain data, all of that  stuff that isn't about how do I actually build an   application on top of it. Just taking ridiculous  amounts - years - project years of time.   I think that more than anything, that's the thing  that will allow the next wave of innovation,   of production innovation, on blockchain  is going to be projects just being able to   iterate the use case level rather than the  plumbing level. Yeah. Certainly with what you say,   it makes you think of a couple of things. Firstly,  with the number of hackathons that have happened   where the output of the hackathon is  getting a blockchain up and running   back in the earlier days and also with enterprise  architecture specifically, it's not had it's sort   of enterprise integration patterns moment where  you've got really well-defined approaches for   integrating these different types of solutions  for this. One of the things though that you spoke   about there as well, was the actual use cases and  the importance of having the right use case too.   What are the things that come to mind about one  of the really good use cases here? It could be   that you give specific examples or it could be  just more than calling out the properties that   you feel very relevant. So I probably will give  just more general answers. But, one of the things   and one of the journeys that led us to FireFly,  that it'd be great to talk about a little bit,   where we're trying to take those patterns and  make them in an open source way rather than it   just being - you come to a company like Kaleido  where every developer should be able to develop   these use cases. What we've seen, maybe uniquely  in our journey in Kaleido or maybe not, is that   we've seen lots of patterns that across industry  beyond the core financial token ones. Just a few   examples, one is around improving business  processes, multi-party business processes. Cases where it takes UPS trucks and planes flying  around the world and physical documents exchanging   to allow ships to leave ports or money to actually  close out the end of some business transaction.   Those kinds of use cases, the  efficiency gains can be huge. So   improving the way an end-to-end business  transaction works is one really critical   one. Another one we've seen which  is really interesting and we've seen   across industry over and over again is enterprises  at their core are about the data that they have   in terms of the IT landscape. When you're  trying to do something in a business ecosystem   of any kind, everybody's got that own source  of truth and their own internal amount of data.   Data on customers, data on transactions,  data on products, data on things   and one of the biggest sticking points is that  everybody is constantly spending time and effort   trying to make their data consistent and correct  and make their data consistent and correct for   everyone else in the business ecosystem. They do  that because there's no way for them to share data   and this is as true as it is for health care  data, as it is for insurance data, as it is for   core sensitive cross-government department  data. They have strong regulations that mean   they have been really careful about  how they share data with each other   but they actually want to share the data with  each other in certain scenarios because they   also have requirements that mean they must  be able to agree on certain core things.   I'll give a specific example that might sort of  bring it home which is one you can read about from   a really fantastic organization, called Wish  Stream, which is part of the institute's, one of   the biggest groups of insurance organizations  in the US. They have a use case around   what they call mortality monitor and this problem  that all of the insurance companies need to   pay out to people in the case of a bereavement.  And the poor people who are dealing with that,   which is incredibly hard for the the actual  people who are dealing with bereavement,   are asked to provide data, the same data,  tens of times during the process because those   individual insurance companies actually being  able to share that information is really tough.   That delays payout of the actual insurance  to the bereaved and it just causes a huge   amount of human suffering, right? In  terms of having to go through that   to actually prove that somebody has  passed away. That problem amazingly   can be solved using blockchain at the core  in a way that it couldn't have been solved   before. So there were use cases that are just  like a world away from here's an SDO issuance or   I've got an NFT of a fantastic football player  that I want to put out there on the web. There's   use cases that are just hugely detached from them.  But the core constructs of uniqueness, things like   tokenization to help the ecosystem work, can just  transform the way it happens. Yeah, absolutely.   So I know that you obviously want to talk about  FireFly as well. This is a recently publicly   announced project within Hyperledger. It's come  out of the work that you've been doing over the   number of years now at Kaleido and so for those  of people who are listening who aren't familiar   with Kaleido, it's probably worth just introducing  a bit more about who Kaleido are and what they do.   Then, I think talking about about FireFly and why  it's so exciting, why it's so relevant right now.   Yeah, that's great Connor, thanks. Kaleido's a  startup that's focused exclusively on this problem   of money party system. So we're a specialist in  the blockchain space and we focus on making this   technology consumable for enterprise. So back  at the beginning, we started with some of the   problems, which as you pointed out back then,  people were spending huge amounts of time on   'how do we get a network up and running?', 'how  do we get the right balance of decentralization   and sovereignty and consistency to actually have  everyone's got a blockchain node?' Right? 'What   does that look like?' 'What's the right balance  of hosted and hybrid etc. approaches to having   a blockchain network up?' That's where we  started. We launched on stage. Our Public   as a Service offering with AWS there were up  on stage as we were the first managed service   that they had and continued to go on to partner  with Microsoft as well and Provide's as a service   infrastructure. But immediately, as soon as we'd  done that, we actually started then building on   top of that and building some of the services  that were new, that didn't exist. One of the   earlier services was how do you get transactions  streaming onto a blockchain. How do you get events   coming off, and then things like organization  to organization private encrypted data exchange   output messaging large documents, building that  sort of stack on top and providing as a service   a sort of solution stack for building enterprise  applications. We work directly with with network   operators and enterprise business networks and  we help all the way from the developments of   the application use cases, the decentralized  app, and the end user experience and APIs,   all the way through to providing that enterprise  grade as a service infrastructure in the back end   that allows this network to have their  software infrastructure connected back   to their organization. It also allows everyone  to go fast enough that they can connect together   and that's why we we also do focus a lot on  providing as a service infrastructure still. So, with these building blocks that you created,  you started to see some common patterns emerging   there, right? And some problems that  you really felt that you were solving   that were probably bigger than Kaleido itself?  Yeah, for sure. You know, it's a big decision   for an organization like ours, that has a lot of  unique insight in the space, to go and say 'well   the thing we were gonna do is we're gonna  take the crown jewels and we're going to   make them available', right? That's a really  big decision and the reason why we felt it was   just what blockchain needs is we were solving  the same problems over and over again. We had the   tools on the truck to do it but when you look at  the blockchain sort of revolution and where it is   and you know as it's encompassing more  technologies, it's still not achieving   the scale that it should be. It's not there yet.  It's too hard to build a blockchain solution.   It's that the patterns just aren't readily  available and we drew a number of parallels to   a technology I love and saw evolve during my  career of Docker. Back at the beginning of Docker,   there were people in the space that were  like 'this is gonna change the world',   like 'this is amazing, the way you can put  any software in a box and make it consistent,   this is just gonna change the way everything  runs', 'it's going to change HA models'. But   Docker on its own was brilliant on your laptop,  but it didn't actually solve the problem   and people like me, building cloud solutions,  were like 'well we need a whole layer on top'.   I built three generations of cloud services before  I came to start Kaleido. The first one we built   the whole orchestration layer ourselves. We built  it, we used the Hashicorp console at the time   and Zookeeper directly and we built it all,  right? We've got the whole orchestration layer.   And then the second generation it was like there  were lots of orchestration layers you could   pick between, Marathon and the like.  Then Kubernetes came along and the game   changed. No projects had to think about any of  this stuff, there was just this brilliant API   programming model and set of objects and you  just used it and the patterns were there.   That piece of the project of 'how do I build the  cloud infrastructure?' went away. And we know   that's what the blockchain industry needs. What  innovators of decentralized multi-party systems   need is the technology to become consumable for  them, not just consumable for this specialist   inside of the blockchain space, consumable for  them and FireFly is our attempt to see that.   To try and start a community that's focused  squarely on making the orchestration layer   that makes all of these technologies  fit together and it embraces the fact   that the block changed just one component. We see  like 20 to 50 components in this, inside of these   projects. Lots of them are application  components, lots of them were off chain. You've got to fit the stuff together and that's  what we're trying to do with FireFly, is make   it easy for the people who have to worry about  everything, not just the people who are worried   about the blockchain piece itself. So, let's break  it down for people in terms of what it comes in   and exactly how it works. So, I'm a business.  I've realized 'hey I could put this blockchain in   to simplify this process that we currently have  that's spanning multiple intermediaries within   our organization' and 'so great we've got this  blockchain, we've got some smart contracts or   decentralized apps, whatever flavor running on top  of it, but that's obviously not enough'. So how   does FireFly come into that and what additional  value-add does it have if you start with this   blockchain application focusing on a business  problem that it's solving? So, first thing is this concept of a multi-party system.  That's what you're trying to build.   Think about what you're trying to build  is different to if you're building it   on a database, centralized. What makes it  different? The thing that makes it different is   everybody's going to be running their own copy of  the application. That's what makes it different.   So, if everybody's going to be running their  own copy of the application, the application   is going to be integrated with a security system.  It's going to be nice and have a beautiful user   experience, mobile web etc., and it's going to be  responsive. You're going to have a whole stack,   a whole stack of tech that each individual  organization needs to run, customize and integrate   to their stuff. So what's that stack going to be?  That's where FireFly fits. FireFly comes and says   'here's a starting point for that stack that you  can build on top of', 'here's a starting point   that integrates with a whole range of back-end  technologies'. So behind the FireFly API, which is   REST designed for developers who work in modern  languages, full stack developers who live in React   and typescript back ends, right? Or,  enterprise developers who are used to   Rest APIs and building Spring boot microservices,  right? Here's a stack that you can build on top of   and you can plug in behind so choose your  blockchain ecosystem, find the one that's   got the best enterprise tech for you, it  can be Ethereum, Fabric, it can be Corda,   those are the top three at the moment.  So, that's where the focus is for FireFly.   Choose how you're going to connect together the  pipes between the organizations, right? They're   going to need private exchange as well, choose  the right tech for that. Maybe, we hope, come to   an organization like Kaleido that's got all of  those pipes pre-built or FireFly's got those   pipes built in as well and the plug points to add  additional pipes. So whether that's direct HDP to   HDP, mutual TLS or messaging technologies  with the reliability and the end-to-end   encryption and just take those off the shelf  and have a set of lego grips that let you do the   blockchain pieces, the money party communication  pieces, and then build your app on on top.   The HA model should fit into the way that you  build your application, the database model should   fit into the way that you build your application.  This component should just fit with the way you   would have built the application before. You  don't have to build your application differently   apart from you just have to need to think about  the fact your application is going to be running   multiple copies and everyone's going to have  their own copy of it. So, sometimes you need to   figure out what state is shared, which usually  most of it's going to be privately shared,   that's just the reality, right? What data is  completely shared? Open to everybody. And then how   is the communication going to happen? And how is  that communication going to be different? Because,   you can share these pieces of information, the  sequence of events, what's going to make it   different? That's kind of the recipe but FireFly's  there to try and make it 10 to 100 times easier   than we've seen it be in the past. That's the goal  of FireFly. Then I guess, to complement that as   well you've got the usual widgets, like a nice UI  for monitoring it and these sorts of pieces too?   Yeah, so the intention here is this isn't a dump  of the piece of bits that we've had. We've done a   huge amount of engineering since the design of  FireFly. It's actually a new generation of the   core technology. We rebuilt it in Go, we built the  explorer, the FireFly explorer, from scratch on   top of it to give that live modern experience that  people expect from a great technology. Because   that's what we know all the open source projects  that we love, do. So we want this community   to be the place where that kind of innovation can  happen. We've seated it with lots of components,   not just the sort of core plumbing pieces but  with the command line so you can have it running   in 30 seconds on your laptop. You can have a full  stack with three members simulated and be working   with the Rest APIs. You've got full open API, free  Swagger, for all of the stuff just there. But,   that's as important for this project as how fast  and clever the internals are, which of course,   is also a big focus. When you're dealing with  privacy, you have to think about what are you   linking and there is a lot of plumbing inside  of there that's about coordination of events,   on chain and off chain, because that's a really  hard problem that the individual components   can't solve. And a lot that focuses on what's the  right model for privacy in these organizations. So   there's heavy lifting code in there as well as the  orchestration pieces. And so the project's just   been donated to Hyperledger from the governance  perspective. At the moment it's in this sort of   incubation stage because it's a new project there  and then as traction grows around it, it'll move   out of that. There should be people listening  to this as well who are technically inclined and   interested to find out about getting involved in  the project. What are kind of the things you want   people to do with it, apart from try it out to  see if there's the potential to use it in their   current projects. What would be your ideal ask  for people who come across the project beyond   that? So, that ask is really strong, trying  to use it, seeing if it does make the problem   you're trying to solve easier. If it helps you  understand the problem that you're trying to solve   as well I think, that's really important. We  want that engagement. Come along to the community   course. They're weekly at the moment, they'll  fall back to bi-weekly once we've got through   lots of architecture, playbacks on what's there at  the moment. But, at the moment, those are weekly   so you can come along. We try and make sure only  the first half is a deep dive presentation and the   second half is just completely open to discuss,  to bring your ideas. So, come with your ideas,   come with your skepticism as well and let's talk  it through. And then, because it's about pluggable   components, there's lots of opportunity  beyond just working on the core FireFly   to work on plugging in technologies. So  the fact that it's multi-protocol means   the Ethereum leg is very mature, the Fabric leg  is actually really in the innovation stage at the   moment and Jim Zhang another one of my co-founders  here, he's worked on Fabric since the beginning,   is helping coordinate the efforts in that space.  So that's nascent and there's lots of opportunity   to get stuck in. There's lots of enterprise  innovation there, so you can get really stuck   in on the engineering side there and the Corda one  as well. We've actually had some previous proofs   with real projects. There's some more innovation  needed to make it fit the whole model because   Corda is slightly different as a technology to  the other blockchains. So that's a whole area of   plugging in technologies. But there's also other  technologies that can plug in the arm blockchain,   like we've got IPFS and we've got private data  exchange over mutual TLS but you know plug in   your own messaging, plug in the messaging  technology and adding building blocks. Then,   one other thread which is going on at the moment  which is really active and we think there's lots   of innovation for is tokens. In terms of building  blocks, the sort of air and water we're building   an application. Tokens and how those sort of core  operations of tokens, which I feel are like CRUD   for databases, tokens are for blockchain. Those  corporations, how those fit with the orchestration   needs to happen off-chain. That's something  that's really happening actively on the project.   So there's loads of places that you almost  certainly have skills that would fit in to the   model that we're trying to enable with FireFly.  It's not just about blockchain skills is a really,   really important thing so the community  is one where probably everyone who's an   engineer has something they can bring to the  community, the community would benefit from. I guess the other thing just to highlight as  well is that there's no fee or anything to take   part in it, it's completely open to all of the  actual community there. You don't need to be a   Hyperledger member or anything like that to engage  with it and contribute to the project. Absolutely,   it's all Apache 2, open source so it's genuinely  open community. Everything that we do is in there,   is in the public and the best place to get started  is you can come to Kaleido, click open source and   go to the FireFly section to learn a little bit  about the background and our seeding of it. Then   just go directly to the  hyperledger/firefly git repo   and you'll get to all of the open documentation,   the actual source code. Repositories there's  actually a bunch of them because it's a sort of an   umbrella project with components underneath it  and the plug-in interface. They all start from   hyperledger/firefly on github and that's where all  of the open collaboration happens. So apart from   FireFly and just governing and growing and  just making making it better and better, are   you focusing on anything else right now? Are there  some other things that Kaleido as an organization   are working on that you wanted to highlight or  future directions? Yeah, it really is just one of   the things that we're doing over here, I guess a  lot of our focus as an organization is on helping   these unsung heroes of the blockchain space, the  network operators, the organizations that form   either by donations of lots of large enterprises  into a group of people or actually as a separate   organization. We are working with, a lot of our  time is actually spent just working with those   network operators, with the business networks  themselves, to accelerate them to build use cases.   And for that reason, we've done a lot of  innovation around the model, the technical model,   for how a network manages infrastructure.  It's really interesting because it's   not just the blockchain components, we talked  about there's the application components as well,   so one of the biggest things that we've  actually been working on over the last   year, is that evolved model for how a network  manages building an application together,   all the way from building and then hosting all  the components. So that's from the technical side,   that's a big focus for us, which is around  hosting management network operations   beyond just the blockchain itself. And obviously  helping organizations, groups of organizations,   usually with a network operator but not always, to  actually deliver value. That's the other piece. So   a lot of our time is actually spent building  applications and helping accelerate projects.   Awesome! So just just before we wrap up, I  know you've spoken about how people can follow   what's happening with FireFly, if anyone wants  to reach out to you or what are the best places   to find you? Is it Twitter, LinkedIn, by the  community calls? What would you encourage?   So, a couple of ways... if it's about  FireFly, then Rocket.Chat is the way to go,   chat.hyperledger.org, you can get us individually,  you can get me directly on there. There's a   FireFly channel that you can go and engage with  the community there. So Rocket.Chat is great. For   me personally, LinkedIn is probably a great way to  get hold of me and I love to have DMs on there. Or   reach out to me at peter.broadhurst@kaleido.io  directly if you want to email me.  Well, thank you Peter, it's  been really great to catch up   and also learn about FireFly as well. It sounds  like it's something that's been missing from the   ecosystem and so it's a big step forward  in terms of enterprise and blockchain.   Thanks so much Conor for inviting me. It's  always always great to catch up. I know we've   been working together for a number of years now  and what you and Web3 Labs do for the community   as a whole is is fantastic. So thanks for having  initiatives like this and ways for people to share   and engage together on these interesting  topics. Thanks Peter, I appreciate it, cheers. you