 Alright, welcome everyone to the identity implementers working group call for June 2, 2022. Thank you for joining us today. My name is shower howland. Today we are going back to the usual order of announcements and then working group updates for the first half and then a presentation from the Firefly team. Peter Broadhurst, Jim Zeng and Nick Geier during the second half of the call. And as usual, since this is a hyperledger call we are following the antitrust policy and the hyperledger code of conduct conduct. There's more information here if you'd like to learn more but basically we are collaborators in this space and we don't discuss anything confidential or proprietary. But of course, as usual, if you do have something able to be publicly shared that you'd like to talk about, whether that's in working group update or presentation. You're very encouraged to jump in and if you do have a presentation idea just let me know and we can schedule you in for a future call. This call is being recorded, and I will post the recording up on the meeting page later today. So we can go ahead with announcements. Today, we are joined by Tim spring who will be a co moderator of this working group with me thanks for joining us Tim. Would you like to take a minute to introduce yourself. Sure thing. Hi my name is Tim. I'm a marketing manager and DCO and I look forward to helping char, book some interesting speakers for the group and also work on growing our numbers a little bit so looking forward to it. Great thanks for being here Tim. Let's see another announcement that we have is the third cardiac interopathon coming up two weeks from today. There are links here with more information. And this is an opportunity for companies and organizations building on the hyper ledger Indian areas code bases to meet and test their solutions against each other and and against a reference implementation of cardiac. And bring their own networks. So this is a really great way to figure out if you have any bugs in your build and fix them. So here is a link to register as well. And with that, we can move on to introductions. Would anybody like to introduce themselves if you're new or rejoining the caller would just would like to say a few words about yourself and why you're interested in this space. So this is more of a reintroduction like just to come to this meeting. A couple of years ago I think it was occasionally. It's been a while. So I'm working on areas from framework JavaScript with the animal guys team on the others been doing that for the last six months implementing a IP to. The reason we're doing that is because I'm working with Ontario and BC gov to do the Ontario digital wallet roll out implementation that they're doing there so all exciting stuff so I thought come along to this meeting specifically because it's nice to actually see people actually using this technology in terms of demos and sort of business use cases which is something very much interested in so hello again everybody if you don't know me. Yeah, thanks for introducing yourself Mike we're really glad you're here. No worries. My name is Sean bohan. I am one of the community architects and hyper ledger and I'm changing my name instead of TSE open IDL. I formally worked on indie and areas back in 2017 through 2019 and recently joined hyper ledger and I've come to a couple of these and I'm super happy to be here and also here with the firefly teams and working on with this it's going to be fun. Great thanks for introducing yourself Sean. Anybody else would like to introduce themselves. I guess folks from the firefly team could introduce ourselves because this would be our first time joining this working group as far as I know as well. My name is Nico guyer I'm a maintainer on the fire hyper ledger firefly project. I'm also sort of the open source community lead so you know, love meeting new people in the community in, in, especially in the broader hyper ledger community and happy to be here today. Thanks. Thanks for being here Nico. I think we lost you for a minute. Peter would you mind repeating that or at least my connection cut out. Sorry about that. Is that better now. Yes, now I can hear you. Yeah. So one of the core engineers working on on on firefly work actually, as well as Jim Nico we actually all are part of a company called collider, which has been focused on enterprise sort of unblocking enterprises from adopting blockchain technologies through as a service infrastructure but also through building a stack that that resulted in us contributing the seeds of seeds of firefly and and certainly based there has been evolving for last three and a half years that I've been involved in. And so we're really keen to share a little bit about it today, and also talk about where there's overlap and potential for the fire project to work with identity ecosystems. Thank you, Jim, thank you. Another maintainer of firefly, specifically we're focusing on features involving fabric support. And before this, I was with IBM. I was a one of the maintainers of hyper ledger fabric. And I'm looking forward to have always paid attention to the great work, the Indian areas, communities that been doing the ID space so looking forward to more discussions with you guys. Great thanks thanks for introducing yourselves Jim and Peter we're we're super glad you're here and look forward to hearing more from you in the second half of the calls. Thank you. With that, it would be great if, if you all would be willing to put your name down on the attendees list just so we can keep track. I just sent out the link to this wiki. But without other any announcements that I'm missing or anything else. Anybody wants to say before we move into working group updates. All right, then let's move on to working group reports. So the, and we'll start with hyper ledger the main identity working group. We've reported on them in previous meetings. So we can move on to the Indie contributors call. I actually missed this call that anybody attend to like to report. Looks like they're still making a call for resources on implementing the Ubuntu 20.04 upgrade so if anybody is interested in helping out on some with them. Technical assistance there I'm sure that'd be appreciated. Let's see. Aries working group call. Anybody attend this one who'd like to report. They have mainly been going over machine readable governance updates and an AI PD to update. Right, the bifold user group. They've been working on an async ledger issuance bug in iOS releases and tab navigation configuration discussion. They're working in the areas college and Python working group. I usually tend this one, but had to miss this one as well this week. But they are still working on getting to the release of acopi 074 I think we've, we've, we now have to release candidate to that we are validating against and I think the next thing will be the official release so that's really exciting. So figuring out exactly which PRs are going in. All right areas framework go. Is anybody involved in this group would like to report. It's like in their last few meetings they mainly went over some work updates for areas framework JavaScript. How about this one anybody would like to report who's involved. So they've mainly been focusing on out of band did exchange issue credential, the two fixes and the JSON of the credential support update among other things but Mike, if you'd like to jump in that would be great. That's all pretty much still the case what I would say is the focus. I'm really on getting the present proof version to over the line. So if you credential present proof version to the sort of two halves of the AIP to equation issue credentials we to is pretty much done. And now I'm going to be sort of focusing on me and the other guys will be focusing amongst other things on present proof version to which is a presidential presentation exchange. And that kind of stuff just fall a little bit behind. There's also a big drive, which we had a meeting earlier today on getting some cool documentation done for the areas framework JavaScript is some work that's in progress as well. Great. Yeah, that's that's good to hear. Thanks for the update. All right. Hyper ledger. I don't believe it met since we last reported on them. That's all the hyper ledger groups that we follow. Are there any other hyper ledger updates that anybody would like to give. Hey, George, Jim, how are you today. Pretty good. How are you. Good, good. I noticed we kind of jumped from Ursa to trust over IP foundation I'll go in and edit this directly but we do have two identity projects now launched with kind of in conjunction with hyper ledger but they're listed as independent projects number one everyone's probably familiar with bedrock, bedrock name is now being retired it's officially going to be known as did any of which is a play on DID and it also is the 119th element on the periodic table or something like that that includes IDM USA a state farm, Centara health systems in in Virginia day on and a couple others and I'll put this on the notes and we'll be looking at a use case around extent a credential a credential exchange where USA a members exchange credentials for health information to be able to do life insurance actuarial calculations for life insurance policies and then we'll be moving to other ones but it'll demonstrate both HL7 fire and health data in conjunction with verifiable credentials on a Indie Aries transit open source stack. And then the second one is the I am project I am capital letters which is a DoD project where we'll be looking at also doing something using in potentially Indie Aries stack maybe with some carry sprinkled in around credential exchange around a non-custodial or custodial or non-custodial wallet and the idea will be various use cases where say a DoD service member can use their credentials to access the non-classified network for zero trust architecture and also use their credentials associated again with IDM USA a for service member insurance or to obtain health care under TriCare Prime at Centara Health. So those are all being fleshed out very preliminary but they are two new independent identity projects in LF. Great, thanks for those updates on on both of those projects and feel free to either update the wiki or send send information or links in the chat, whatever is easiest for you so thank you for jumping in with those. Sure, absolutely. All right. In the trust over IP foundation. They had their last all members meeting just before our last meeting two weeks ago. Looks like they, they mainly went over EIC updates and then updates from all the working groups which we are about to go over. Let's see in the steering committee. They met recently looks like they mainly shared updates for upcoming events and special topic presenters across our working groups did anybody attend this meeting to like to report on it. All right, we can go into the specific working groups. Communications committee mainly went over blog posts, there was one that was just posted on decentralized identity keys to mainstream adoption. Anybody involves in this group who'd like to report. All right, in the governance stack. They got an update regarding the governance template documents for use at all layers with the primary documentation companion guide. And they also have a governance one on one webinar from conception through governance documentations. But Kyle did you want to jump in. Yeah, yeah, I just have an update on that one so we had a good meeting yesterday with the task force leaders for the governance layers with Scott. And so we're doing a bit of a pivot actually. And there'll be more information coming shortly on that. Really it just comes down to the templating of the governance documentation. We want to put forth. And there is supposed to be a meeting today but I think Scott is canceling it. So you can look for if you're planning to attend look for that update. Yeah, great thanks for thanks for letting us know about that. All right, the technology stack working group. Their current focus is the to IP architect or technology architecture specification be one. They've developed a generalized reference architecture for defining the four layers of the technology stack. And they're currently in the process of adding the details and requirements necessary to complete the V1 spec. So let's see the utility foundry group. Again their focus is the public utility directory. They're also working on a framework for evaluating layer one utilities, which is an overview document. They're also collaborating working on new collaboration to focus on layer one governance. And let's see the ecosystem foundry group. They're working with the governance stack working group to combine what they're doing at the ecosystem level it's with what's happening at the governance level and then they've reported that the biological ecosystem white paper is almost complete. And then concepts and terminology. And then on on the to IP core to backfill the to IP core and gov stack working group glossaries. All right, any, any other to IP updates that anybody would like to get. All right, we can move on to the diff. We'll start with the did come working group is anybody involved in this group would like to report on these last several meetings. We've only been working on this context update PR and then a discussion on adding a, a size specification for did come messages. There is a link if you'd like to learn more about that. The did come users group. Again, this is the unsink media that is held over a 24 hour period. They reported that the did come be to spec was formally finished on Monday. It's working group approved, which is as far as the standard goes at the diff. They reported. So that's exciting. Let's see diff interoperability group. They've had some recent meetings canceled but their next meeting will be June 8. So we will report on that in our next meeting. The diff updates. All right, sovereign foundation as far as I know they have not met since early February, but definitely let me know if I am missing information there. And then we can finish up with the W3C standard in the did working group. I don't believe they've met since we last reported with the community credentials group. Looks like their May 31st meeting was canceled but does anybody have any W3C standard working group updates or any working group updates in general to finish off with before we move on to the presentation. I guess we're going backwards, but on the sovereign side. It probably worth and I can add this to if you want just including the SSI and IOT working group under sovereign we meet on a weekly basis though it's canceled this week. And, and I think we've been progressing pretty well in terms of both building proofs of concept for hyper ledger Indian areas ported to rust to be able to use at the at the device level at the IOT level, as well as just academically exploring and promoting the concepts of verifiable credentials as part of IOT zero trust architecture concepts to so so that's one I'm happy to report on. Okay, great. Yeah, it sounds like things are going really well I will, I will make sure to add that in so that we are reporting on that regularly so thank you. All right, any other working group updates that anybody would like to share. All right, thanks everybody who jumped in with updates from projects they're involved in I really appreciate it. I think with that, we can turn it over to Peter Jim and Nico you should be able to grab the screen share if you'd like but I'll pass it off to you and look forward to hearing your presentation. Great. Thank you very much char. So I think I'm going to kick things off. I'm just going to give a quick quick agenda of kind of what we wanted to go through. I'm just going to give a very brief, very brief overview of what Firefly is what the project is how it's used, and kind of the snapshot of the roadmap of what we're working on currently. And then that will kind of segue into Peter talking about how identity works in within Firefly, and then hopefully from there we could kind of open it up and have discussion about it. So my, my other disclaimer is that before about a couple hours ago this morning I didn't realize this was going to be a presentation. I think it was more of a conversation so here's my disclaimer. I'm going to go ahead and share my screen, because I do have some slides to go through here, and we'll jump right in. So, just kind of want to give folks if you're not familiar with the Firefly project. Like I said a very brief overview of what it is. I could talk for a really long time about this but I'm going to try to keep this short. So, we describe Hyperledger Firefly as a super node. And we describe that as a complete stack for enterprises to build and scale secure Web3 applications. So, what does that mean? Well, that means Firefly is not a DLT. It sits a layer above the blockchain, and it is a platform that you can build Web3 blockchain powered apps on top of. So, what does that give you as a developer? What's the benefit? When you look at the landscape of open source projects, there's a lot of projects down kind of at this low level of blockchains, DLTs, all these tools for doing stuff on the blockchain. That's great. There's lots of, there may be lots of stuff at the top layer too, where you have your user interface, and there's lots of great open source frameworks for building flashy cool Web apps. But if you want to build an enterprise Web3 application, there's all kinds of things that sit in between those layers that you have to build. And one of the things, as Peter was saying, this is Firefly sort of came out of the journey of Kaleido at Kaleido as we built more and more Web3 applications, we realized that hey, all these applications need the same or very similar set of plumbing and pipes and connections to different things and messaging buses and event management and all this stuff that sort of sits in between these layers that lets you build a really robust enterprise Web3 app that can scale and is secure and is ready for enterprise production. So that's what Hyperledger Firefly does. It's meant to fill this gap to give you a common platform with an easy, concise set of APIs that you can build an application on. So it sits, like I said, a layer above the blockchain itself and lets the developer focus on the thing that's really of ultimate value to their business, which is solving their business problem. So developers can focus on the logic of their business app. They don't have to spend time thinking about, well, how do I actually get data from this one piece of our network architecture over here, over here, Firefly handles all those things, has connections for all those things. So what's in the box? We can sort of think about Firefly in kind of providing three major categories of things that allow you to build apps, flows and digital assets, and I'll kind of break down what each of these are in just a minute. So those are like the main sets of things that it lets you do and build. Those are powered by the Firefly Core. Firefly Core has an orchestration engine in it that is sort of the brain and the connector and the organizer for all of these different systems that it's connecting. And what are all those systems? Well, there's obviously a blockchain node. There is a shared storage service. There is a private data bus for privately exchanging data. Firefly Core has its own database where it's keeping track of state of the network of things on the chain and also its own internal state as well. All of this, of course, is done with security. This is enterprise ready. So there's security running through all these layers. There's also a really robust set of tools kind of have on the chart over here. There's an SDK for Node.js. It's written in TypeScript, so it has great type definitions. There are more SDKs coming. That's the one that we have today readily available on npmjs.com. There is a command line interface that can be used to create a local development environment on your machine that will start all this stuff up and lets you play with it with just a few commands. And obviously there's a fantastic API for all of this stuff. There is a web UI, the Explorer. I forgot to mention here at the top. The Explorer is a fantastic user interface that lets you see what's going on inside Firefly. And all of this is designed in a cloud native modern distributed architecture in mind. So it's meant to run in Kubernetes. It has Prometheus monitoring built right in. And it's great. So let's kind of break down kind of these apps flows and digital assets and describe a little bit more in detail what we mean on each of those. So one of the really cool features that Firefly has is that it will let you build HTTP APIs from smart contracts. So you can import a custom smart contract. In Ethereum you could provide an Ethereum API and Firefly will generate on the fly an API for it. So it lets you sort of rapidly build integrations and applications. It also stores information about the about the API on the chain and could broadcast that to other parties as well. You can inform other parties about a certain contract that's on chain. And there's some really cool features there, including the ability to subscribe to events being emitted by those contracts to index those events and be able to query them and get state out of the contract as well all through Firefly's API. Firefly is one of the main use cases for it and this is a use case that is growing. There's a lot of functionality being built into it right now is to use it as a Web3 gateway. And what do we mean by that. So, for example, if an enterprise has they want to build a an app powered by blockchain, but they need to have a control point or a one point in their IT infrastructure that is can communicate with a public chain for instance communicate outside the business network that needs to be in a very specific area of the network Firefly can can fill that role so Firefly becomes the gateway to the Web3 world in the same way that an internet gateway is a mechanism for applications inside a network to reach out to systems outside of the private business network Firefly can act in the same role for the Web3 world. And this can go both ways as well so everything coming to and from the blockchain goes through Firefly and to a Web3 app. So this provides a lot of power for businesses. One of the other use cases are sort of usage patterns I should say it's it's much broader than than a specific use case but we describe as a usage pattern is for consortiums or multi party networks as we refer to them as sometimes. So, and this was this was really like one of the very first usage patterns that was built out robustly in Firefly. So, a lot of the demos that you if you've seen a demo already a Firefly it was probably the consortium multi party usage pattern demo, where you have multiple organizations that are interacting with each other through the blockchain. They're broadcasting data throughout the whole organization hashing it pinning it to the blockchain. Maybe they're privately sharing more sensitive pieces of data directly between members, and they can perform transactions with with custom smart contracts as well. And so Firefly allows these consortiums of businesses to build a network powered by blockchain to perform business transactions with each other, all through the chain. Okay, and that that third box was digital assets so Firefly also comes out of the box with really robust APIs for tokens, which are one of the fundamental building blocks of a web three app of a blockchain app. Tokens could be fungible or non fungible there are our patterns for both in Firefly. And it is, it doesn't actually matter which specific token contract to use it could be a vanilla off the shelf open zeppelin ERC contract whether that's your C 20 your C 721. It could be a completely custom token contract, and as long as it implements the ability to mint transfer and burn tokens, it, and Firefly also has the ability for token approvals as well. So there are first class API is built right into Firefly there's a fantastic dashboard that lets you inspect everything. This is a little screenshot of the, the Firefly Explorer the Firefly UI that shows kind of what's going on inside this particular token pool, but there's great support in the box makes it super convenient. We've had a lot of people come to the project and try it out, just so that they can actually learn about tokens because Firefly provides just a really easy on ramp to get up and started running a system being able to to mint some tokens transfer them play around with an external wallet and just understand how different token contracts works and it's been really great. I'm going to go through these next couple slides, maybe a little quicker, but one of the just briefly touch on the Firefly core. And so the Firefly core is it's important especially to the next part of the conversation as well when we start talking about identity Firefly core is we have, there's a picture of a brain in the middle of this diagram because we often refer to it as the brain of the system, and it's sort of the, it has inside an orchestration engine that is in charge of making sure events are delivered in the correct order based on the ordering set by the blockchain so that the ordering is established by the chain. But then Firefly in the orchestration engine needs to make sure that everything stays in that order as the, the events are presented to the application, as things are put in the database. And it handles, it handles a lot of the heavy lifting of the grunt work of what an application developer would normally need to build into their application to have a reliable. You know, stateless Web three app and the Firefly core orchestration engine takes a lot of that for them. So it's, it's coordinating between things that are on chain data that's being pinned to the chain or tokens or events that are coming off the chain. And it's also coordinating that with with off chain data as well, whether that's documents that are stored in IPFS, whether that's private messages that are sent directly from node to node, and all kinds of things like that. So I've touched on a couple of different places that the Firefly stores data, it has a, like I've said it has a database that Firefly stores network and chain state in. It also works with a shared storage system right now that the implementation for that out of the box is IPFS. And it also has a private data exchange as well. Firefly has, like I said, a lot of tools with it. Here's another screenshot of the explorer from the dashboard. I've touched on quite a few of these already the CLI API and the SDK so I won't belabor the point but it has a lot of tools and they're really great. They make using it easy. And I think an enjoyable experience for developers. It's all like I said cloud ready modern distributed architecture design. One of the other really cool things about it and it will talk more about plugins here and just a little bit is that it's one of the points I haven't touched on is that it's a very pluggable architecture. Not only is Firefly itself distributed into many micro services. The the orchestration engine has a really robust plugin system that allows the implementation for any of those services to be swapped out so if if you're the out of the box implementation of shared storage is IPFS. But if you have a specific need to use a different shared storage mechanism, maybe it's you know Amazon S3 or some other, maybe it's some on premise data storage system that can easily be swapped out via a plugin to the Firefly core to talk to a completely different storage service that sits outside of Firefly core. So it's both a microservice architecture and it's also a very pluggable architecture as well. So a quick comment on kind of the roadmap of what we're working on and then we'll segue into the work on identity kind of we're working a lot right now on enhanced support for public blockchains, as well as multiple ledgers and blockchain connectors at the same time, and in different usage patterns at the same time so I talked about kind of the gateway and the multi party usage patterns, allowing Firefly to to operate in both of those modes at the same time. In different namespaces with different sets of plugins. And so so all three of these active development bullet points are very much related so I also commented on that you know there's there's a lot of work going in right now to enhancing Firefly's Web3 gateway capabilities and giving operators more control more granularity of how their, their, their Firefly node interacts with the rest of the blockchain world. So coming up soon, we're working on more samples more SDKs, and looks like I had a duplicated bullet point the Web3 gateway was supposed to be in the left side sorry about that. And also pluggable API security and pluggable identity management are coming up very soon. And so those are those are things that people are really excited about as well. And so speaking of pluggable identity management. I will end my, my little slide where talk here now and I will turn it over to Peter to talk about that topic. That's, that's great. Thanks Nico so let me let me just share my screen. And just to give you a feeling for what Firefly is firsthand. So if you stand up Firefly, and I do encourage you to have a look at some of the recent demos and we can send some, some of those, those through afterwards. So see what you get in about five minutes when you choose fabric or private Ethereum chain or maybe even connecting to a public chain. You'll, you'll get a stack on your, on your laptop which is running everything you need. It's running all of the Firefly components, which is a micro service architecture part of making it pluggable is allowing different languages. So it's, it's running a bunch, bunch of different, different containers for you, including the blockchain IPFS. And like I say, you can, you can pick your pick your blockchain there, and also a bunch of tooling. So you get a sandbox, which is sort of an exercise for blockchain constructs. So being able to play with tokens, create or launch your own phone, your own token on your, on your laptop transfer mints, mints and burn tokens, interact with smart contracts of any description on the blockchain itself. So you've got some custom fabric chain code you've got a custom Solidity smart contract being able to generate a rest API for that and interact with it. And, and also Firefly helps you coordinate together the off chain pipes that exists pretty universally across enterprise deployments of a business use case on blockchain, whether they're well organized between the multiple parties as part of a sort of multi party application that everybody's running a copy of, and sort of the off chain pipes are standardized between everybody who's building in that solution, or whether it's much more ad hoc. The reality is that blockchain isn't great for sensitive data going directly on the chain so you need to coordinate off chain transfer with on chain so that pass and again it's all built into into Firefly. And you'll also find you get an explorer, which as Nico showed a little bit gives you a bit of a view into into the systems on my space there. And what you what you've done on on your on your node lets you drill into all the different things that Firefly can do. And obviously, if you are going to be doing things like off chain coordinated transfer of data between different organizations. And what that means is you need to know who you're exchanging data with it's just don't need to tell this group that that's a reality of life in the blockchain space that a head string when the theory address is not great for business to know who they're working with. So, so far fly does come out of the box. When you're using it in the multi party system mode, where you're assuming everybody else is running. I fly nothing that's an important point because our flies and technology does not make that the same assumption that does provide that as an option for you. So once we're sort of built in network map a system of identity just out of the box inside of inside of Firefly. So, just before we started talking, I sense, I sent a message that came from another party in the system I need to see who it came from. And I actually get to see the, the identity that came, but that message came in on. So if I open up the message here. That we represent identity in fire fly using the DDS syntax. And I want to put it that way because we far flies itself, just like with every blockchain technology, not trying to be the full implementation of core blockchain constructs. Firefly is not a DLT. It lets you plug into fabric, ethereum, even as called a call to support there, connect to all of those remote blockchains that you might be connecting to even things as varied as Bitcoin are, you know, fit into the pattern of firefly off chain pipes, or maybe you're using, you know, just the open source mutual TLS connectivity peer to peer, maybe you're using a queuing technology like rather than queue or Nats or, or, or Kafka, or JMS provider but all of that can can plug in. And that was the reason for choosing DID to be the way that we represent an identity of something that you've received in this particular case, a piece of broadcast data that was pinned to the blockchain with a blockchain has action at the hash. So all sensible solutions, the data itself didn't go on to the blockchain itself. In this case, broadcast went into IPFS, but my firefly node is telling me it's done verification, but it's from this author. What does that actually mean? Well, in this case, it's using the built in identity system of the modifying system of firefly. And that is the only options there. I think that's a really interesting thing to get to in a minute or so when we sort of have a bit of discussion at the built in identity system. And so there's a, there's a, you know, a DID was older, but we just picked up a firefly to say that this is the built in resolve inside of inside of firefly itself. And if you go to the network map, you'll see that there are these sort of constructs like organizations knows and customer densities which I don't have any of, which are a, which are a, a simple built in. With a sort of profile way of advertising your identity within the network, which is backed by performing a simple verification using a key. And I don't have an example of it here, but if there was a charlotte entity, like I created a custom identity, but it wouldn't just be the identity you would, you would have had to be the key that you're using yourself to prove that you have ownership of, there would also be a verification by whoever you're saying is the is the next identity of the tree. So a very simple system, you know, a lot like a PKI system, where there are some root identities in the system that are trusted because they just established themselves through sort of a gatekeeper construct they came on board and then a claim of verification system to generate other identities where you need one transaction on the blockchain from the parent to say they, they attest to your claim, and you know, pretty simple, simple solution. But what really makes this sort of interesting is with a fully pluggable architecture. Why not have other results, right, why not have firefly in much more sort of in that gateway mode where you're just connecting to ecosystems that exists, where some of the members are getting the acceleration of using a stack of technology like some of the members know maybe built everything from scratch and really want to use the lowest level technologies, and being able to join that community and participate in it using sort of middleware stack that makes it much easier for you to connect your applications and Well that would mean you'd need to work with whatever the identity system is of that group of participants. So that's why we chose the idea we're not choosing the idea because we want to be a self software identity provider we're choosing the idea because we want to be a accelerator for solutions, regardless of what technology choices they've made in the blockchain space. And that means that projects where there is a self software identity system or other identity system involved, that's backed by DID, they're going to plug that in and say, don't resolve this inside the firefly with the multi-party system built in thing. Resolve this using the plugin. And the plugin doesn't need to be, you know, just because maybe firefly cool is go doesn't need to be rewritten in go like that can be any existing system. If it's got APIs, if it conforms to the standard, it can be, it can be plugged, it can be plugged in. So, sorry, I talked quite a bit there but I really wanted to give that flavor of sort of what it is, but also what it isn't for this community because I didn't want to give any impression that what we tried to do is, you know, that there's a synergy with projects like Aries and Indy and software, not a contention with them. This is about an accelerator that helps particularly focus on enterprise projects go faster in Web3. It's not seeking to replace any of the technologies, whether that's the DLT layer or technologies like I get there, some quite big transfer and self software identity systems. So I will pause there and I hope maybe there's some questions. I wonder is firefly new to some people on the on the call or is this is this mainly been a recap. Peter, there's a couple questions in the chat. I'll just throw that out to you. Yeah, and just just to answer your question. This is Kyle Robinson. Firefly is new to me. And I'm still not sure I understand what it even is. I've been in the Indy Aries space and so I'm trying to see if it, how it equates to something in that world. Maybe I don't have it yet. Okay, let me let me try again. Nico, maybe you could bring up the chart that's got the layers of stuff that you would need to build yourself if you didn't have sure you pull that back up. So, so, so you're, you're, you're a developer. You, you understand JavaScript reacts, you know, Java, microservices, and you're pulled into a team and you're told, the next project's going to use web three technologies. And it's still going to be an enterprise project is still going to be still going to need to puzzle security views it's still still going to need to be done, done with all of the standards that we've got but it's going to be a blockchain project and maybe it's a new one and you're building a new use case on web three. And you're going to be collaborating with a bunch of other companies to build it. Maybe there's an existing thing that's out there like some tokens and digital assets, an identity system. Somebody there it's been built for the last five years and the project is your company integrated with it, you know, launching a launching a new digital digitized piece of value or performing a some, some, some, some a collaboration with a doubt that exists out there, right. And what do you do is the first thing you need to do, go and learn solidity and Jason RPC and what you know how I'll be encoding how it works and how, how to deal with the you know streaming like calling for events and we're recovering and doing checkpoint recovery on events, dreams, and how to, you know, work out how to go from an API to a piece of code that can invoke something reliably at scale and do with key management is that we all your next six months is going to be is learning all of that and maybe at the end you'll get to okay now we can actually like some business logic, or is there a stack out there and start with a business logic, the blockchain stuffs, just as easy right when I'm when I'm doing database applications I don't, I don't learn how to write the database source, you know, in order to use it, I just, I just just start building my application in a framework that understands how to integrate databases I use a, you know, I use a library but let's me connect to the database and away I go and it behaves well and, and I can do it at scale and it's reliable. We've seen, I mean it was passively true when, when, when, you know, number of people who've been involved in far flight sort of since its original inception. Five years ago was the projects would spend 80% of their time on the plumbing. It was astonishing how much time was spent just doing the low level plumbing pieces and not on the blockchain. And the fact that there were all of these projects that were able to help at the DLT layer, but nothing that helps the application developer get API's that do what they need them to do was really surprising. So we're trying to make this an open, pluggable way to provide API's at the level developers need, particularly enterprise developers, and deals with those really hard plumbing pieces in the way that there's, you know, it's done in the open. It's, it's not so much a standard driven approach but more a driven through adoption approach to have reliable set of building blocks of all the set of sort of middleware to build on top of. Does that make a little bit more sense. I understand what you're saying. I'm just not kind of lining up with what I know. And I think part of the part of it is, I don't know and maybe others can correct me is we don't really have a concept of a Web three app in in the Aries, we have wallets that do changes with fair viable credentials. And you know maybe somebody's got a mobile version of a wallet, or an enterprise version of a wallet that does that exchange, but not necessarily an app. Yeah, do you have an example of one of the apps that's been you built using the Firefly framework. Yeah, so I guess when you look at the enterprise participation in a network where that is a decentralized identity think about the enterprise that's deciding. Do I do I do I test to to a claim that somebody's made. I want to build an enterprise system as you know a piece of the government or university with a large IT organization security standards have to think about roles and integration to I am systems rather than rather than just end users, like just you directly with keys on that on that on their phones. Building a system that you know needs to run at scale, I believe they'll be a big application stack with sophistication on like where were the key store which you can assign the other stations where, where, where's what's the system of record to know what I have and done, how do I which query that to see somebody saying you're testing to my density on this on this date, did we really do that to be not that kind of enterprise system. In my experience tends to be really quite a thick application stack it's not just not just a website library inside of running on a browser on a phone. So that's the kind of, you know, place I would think it would fit into the ecosystem. Yeah, and I think I see the value in it I just, I'm trying to see it's interoperability or applicability to what we're doing. But I said enough asking a question. So we were asked to come to this one together, really. So we didn't come in with any preconceived ideas that like this is the exact place where it would or it wouldn't fit. And maybe the answer is that the projects right now, this sort of enterprise integration, sort of the people being able to build solutions stack is just not where the communities at and if that's the answer it's not it's not a concern from my perspective. Right and I'm not trying to shut anything down I'm just trying to see where it might fit. That's great. I have a question that this, this, this fire, firefly framework really reminds me very much of hypernetics composer a few years ago. IBM tried to build a framework on top of fabric they wanted to make it blockchain agnostic they were providing the API is trying to make life simpler for application developers and it failed miserably. So I'm going to keep up with the vast rate of change of all different fabric SDKs anything else. If I understood correctly you're trying to do that plus Ethereum and quarter and whatever other underlying blockchain so my worry would be for, for you guys how are you going to keep up with all the different underlying blockchain sort of API is because you're building a layer on top of that so is that something that is out of concern or have I got that wrong. So I was, I was, this is Jim, I was part of the team that was helping to build the composer. When I was IBM, the problem with composer was number one this, it's sort of ahead of its time. Number two, the fatal flaw with composers philosophy is it's a very heavy handed approach. There are DSL and then you compile it into a bunch of components that are in the end is quite cumbersome to iterate, like when you, the problem with generating stuff is when you need to make some changes, everything needs to be redeployed. And it's, it's trying to sort of solve the same problem of adoption making blockchains easier for the application developers but composer just took the, the wrong approach that makes adoption really hard. And it's not trying to solve the problem of how do we design the, the on chain logic of blockchain applications. It's trying to solve the problem. Someone's going to have to build all of these layers. Anyway, can they plug them into a framework and do less coding still working in the language that they're working in. So they need to add connectivity to a to an ecosystem that's not supported. So to just overall reduce the load on the developer so it's a slightly slightly different approach to try to say look, model your application in this world it's not nothing like a damel would be for example what no one, not like that at all it's about saying, hey, the blockchain specialist has built it the way that they built it. Now I need to integrate with that I need a rest API for it, I need to benefit streams format, I need it to work for me. And knows those layers building them from scratch is the only other option that's out there at the moment and it's thousands of lines of code projects. I think it's a really, we smile because I think it's a really interesting housing, but but there is, there is a different approach, I think to provide them to sort of compose it and it's trying to address a slightly different layer of the stack. Yeah, I get that we could talk all night we're running out of time so I remember three or four years ago we built some composer stuff. I was, you know, you probably know Dan Selman of the IBM guys. I met Dan at Hyperledic Global Forum in Basel actually and in Phoenix funny enough and he was telling me all the same stuff you've been telling me. And the worry is that you know the same thing will happen that we built all the stuff in Composer now we're going to be on the fly flyer that fly flyer isn't there anymore it's like oh what do we do now because there was a lot of very disappointed people in Basel that I was speaking to built some really cool stuff using Composer. I do accept your point about it's a different beast and all that but that would be my that would be my concern anyway. We'll have to leave it there I guess char because we're running out of time here. Yeah, yeah sorry we're going over a little bit is there a question I know that there are people I'm sure who will watch the recording who can benefit from these even if a lot of people have had to help off. But I was curious is there a limit to how many blockchains can be plugged in at a time. In 1.0 which is generally available and it's what you get if you if you run the stack. You know just just use the tooling and stand stand up the stable version on your laptop you'll get 1.0. And there you can plug in multiple blockchains to a note but only with tokens you can't just plug them in at a raw level have lots of different blockchains on 1.0. And that is changing it has already changed in the main line of the code so that these namespace constructs inside of Firefly and you can have lots of different namespaces each of those namespaces can use a bunch of different plugins. So it doesn't just include the blockchain plugin so you could have a different blockchain plugin if we didn't know if we went further with the identity plugin have different identity plugin for that main space and your application could connect to all those different namespaces and integrate with all those different those different blockchains. So there's two parts of the questions right now today there's an imitation of one but it's not architectural and it's already gone in the main line and we'll be rolling it's the next minor release when that comes out. Great. Great thanks for thanks for walking me through that. Looks like looks like Jim Zinclair had to drop the off the call before asking this question but maybe he'll be able to follow up with you after. But anyway, that was a great discussion apologies for going over time but I'm glad we had so many good questions. Thanks, Nico, Jim and Peter for such a great presentation and demo. Really appreciate you being here today. Great. Awesome. And everybody watching the recording. Thanks for joining thanks for watching and we'll see you all again in two weeks. Alright, have a great day. Thanks. You too. Thank you. Bye bye. Bye.