 What's called that? It's a pump to be there. Last DevCon, so DevCon 4, Mike and I were just roaming around. We didn't actually have an official talk, but it was super funny because everybody was talking about the entity. It was around the same time that Eve 2 was evaluating the ability to beat, to adopt it, and so on. So it was a lot of buzz, and we ended up realizing that people actually wanted to learn about the ability. People want to up their skills and understand what this thing is all about. So we ended up working as a collaborative workshop on the last day, very impromptu, relegated over telegram, and very self-organized. We had a turnout of, I don't know, 40 to 50 people in a tidy room, and we had to move all the furniture around and sit on the ground. So it felt like the start of something very special, and this marriage between the theory of it and the ability to beat. And the fact that we actually have official sessions this time, so it's great. We have, this is one of two sessions that we are running here at DevCon. What I'm going to talk about is what has been up in the creativity project over the last few months, and what's coming next. A lot of super exciting stuff coming up next. So I have a lot of ground to cover. I'm going to go super, super quickly. I don't even know if I'm going to be done with this in time, but if I don't, come talk to me. Come find me. I'm going to be around. The second talk that we're going to be having at DevCon is about gossip talk. So a lot of people, gossip talk is an important protocol that is being adopted at the Eve2 project, and a lot of people have shown interest. So we decided to do kind of like a deep dive in gossip talk, about gossip talk that's happening on Wednesday, Room B10, and you've got the details in the slideshow. So I'm just going to get started now. So I see a lot of familiar faces here. So who's actually a user of LB2B right now? Okay, that's pretty cool. Who contributes to LB2B? Nice. Okay, we've got a table there that's contributing to LB2B. That's awesome. So let's get started. As I said, we have a lot of ground to cover, very little time, and what I want to go through today. So who's actually pretty familiar with LB2B? We'll just say like, who's the five that need to be more or less? Okay, five and above. Cool, awesome. So I think the one on one is going to be important to go through today, that I'm going to talk about what we've shared in the last few months and what we are actually building and what's going to be shared over the next few months. So yeah, cool. So let's do a little intro to LB2B. So LB2B is a modular peer-to-peer networking stack. It is, I like to call it a layer zero of decentralized platforms because it basically is, so if you realize everything that we're building here, everything that's going to be built in this conference by teams that are attending this conference and so on, rests on top of unstoppable networks. If we don't have a good peer-to-peer, block-solid networking foundations, we have nothing, right? Because the very nature of everything that we're building is decentralized and decentralized means that different nodes around the world without knowing each other can operate across a set of protocols and across a set of processes. So LB2B is a modular peer-to-peer networking stack, which is essentially a composable, it's a composable set of built-in blocks to assemble a free peer-to-peer network. So it runs on many run types, server, browser, there have been experiments in mobile environments as well and soon there's a team that's working on making LB2B run nicely on embedded devices. It originated in the IDFS project and it's right now implemented across seven different languages at different levels of maturity. This is bustling cross-project community. Initially it was created by PLA protocol labs and it's stewarded by protocol labs, but by no means does protocol labs own the community or the individual. At this point in time it has become a public, right? It's being adopted all across the end of the system. It is currently licensed officially under the MIT stack, but soon we're going to be transitioning under the MIT license. Soon we're going to be transitioning this to the privacy license stack, which gives you even more guarantees in terms of us being not claiming to hold any rights over LB2B. So LB2B really hinges on this concept of decentralized process addressing. What is decentralized process addressing? The grand vision of LB2B is to provide the ability to locate, connect, authenticate, negotiate, and interact efficiently with processes around the world, no matter where they are, no matter what transport they're using, no matter what runtimes they're using, as long as their identity is cryptographically derived from their public key. And LB2B really tries to make this happen and see this matter by taking care of natural reversal, relay, active switching, and a few other things that are important to make sure that different processes that are running anywhere in the world can find other processes in this global fabric that is the internet and interact with each other. Even as those processes relocate, roam, evolve, mutate over time. The concept of process addressing is completely juxtaposed to endpoint addressing, which relies on targeting a process by where they are in the world, by an IP address. So LB2B, as I said, is a stack of composable building blocks, and these building blocks are transports, multiplexes, secure channel, peer discovery, pop-up, controversial, and several other things that I've not even mentioned here. So think of LB2B as a toolbox to assemble the networking layer of a decentralized platform from composable pieces, kind of like a network puzzle. These elements plug into each other by abstractions, and each of these elements can have multiple backing implementations. So for example, we have multiple transports, DCP, QUIC, there is a group of transports that's up and coming, then we're working on UDP, so there's a number of backing implementations to each of them. So that's kind of like what I have, I have very little time, so this is what I have for an intro, and now we're going to talk about what we shipped in the last few months, and this is super exciting. So we have, so LB2B has seven native implementations, which are not shipped, the shipping and signature, right? Nothing is ever done at this level, right? What's cool about this is that each community, each implementation really is backed and supported by a different provider, a different community, a different team in the ecosystem, and these teams are actually working. Hey, we've got some of you here, so we've got, okay, raise your hands. Say this over there, so we've got LB2B, we've got the signal frame team over there, that signal frame team, Rust2B2B, that's working with the weapon foundation to implement Rust2B2B. We have others, I think we have the Java team around. Well, we've got Go and JS over there, this is pretty cool. So what's cool about this is that all of these implementations actually follow the LB2B specifications, so they're interoperable with what I know. They are at different levels of maturity, so the three most mature ones that we consider are JS, Go and Rust, and Pilot, B2B, JVM, and NIM, are mostly driven by the Ethereum 2 project, and CBB and LB2B is driven by the Polkadot project. So this is pretty cool, and what's great about this is that each implementation in a way also targets specialized environments, right? So in the case of NIM, they are making a strong effort to target embedded and constrained devices, right? In the case of JVM and LB2B right now in the current version, it is a Java implementation, but in the next version it will be very geared towards Android as well, right? So this is, you know, this is pretty, I'm very happy about this, right? So in terms of adoption, the adoption of LB2B over the last few months is somewhat skyrocketed, and it's been kind of like a network network effect that's been amazing. So what's cool about, so here you've got like a few of the adopters, some that are that are worth mentioning, of course Polkadot, Ethereum 5.9 BFS, the kind of like the top ones over there, and then there is ZRX that's doing a lot of awesome stuff, OpenBazaar that I've created, another introsport for LB2B, and that's what's cool about all this traction and having a, basically having a bunch of communities that when you look at how they would have built their networking layers from scratch, they would have looked a lot like one another, right? Because that's, like they all share the same concerns, right? So connectivity, addressing, peer discovery, natural reversal, these are things that are common across the ecosystem, right? So there's no point re-engaging the wheel at each of these projects, and what's cool is that all these projects are now collaborating with the LB2B open community to pull their brains and the hands to build a broad-solid networking foundation. And what's great is that most of these projects are actually contributing actively to, so not just using the technology, but actually contributing. A few weeks ago, we also saw the seven-way interop let-off of the EVE 2.0 projects. So a bunch of teams actually locked themselves up in a few cabinets in Canada and came up with a network of a LB2B-based network of all seven clients built at different languages interacting with one another. And this is impressive. This is a tweet that was super popular by Johnny Ray, who I don't know if it's in his room right now. Cool. So a few weeks ago, we also launched DebtGrants and we made, so DebtGrants is the place where we're going to be publishing and you get, where we're going to be publishing work that we would like to get done, but it's also a collaborative space for different projects across the ecosystem to publish items that they would like to ship in LB2B and co-fund those items and pool funds together to make sure that those happen. And at one point, we're speaking as well with a few teams that are going to help us fund much of this work via Dallas and a few other things. We also awarded a bunch of bounties that you bring in, and that was hugely successful. We've also shipped talks and specs. This has been a long-standing issue for the VCQ project thanks to everybody who stuck by us during the direct times while we didn't have good conceptual dots. We now have an amazing website where we engage in a full specs rewrite to make sure that the specs actually match and they're aggregate with the implementations. We've created a specs maturity cycle, we're defining an RSC process, so we're maturing a lot in terms of, you know, the things that are just not cool. We've launched the discussion for us as well. So if you have any usage questions, if you want to start a discussion about things that are not necessarily bugs or change requests and so on and so forth, this is the place to go and not really get help. And we've shipped a bunch of features as well, right? So this is just a list of the ones that came to mind. We've got we created an auto relay experiment, so we launched an auto relay experiment at IVFS, gathered a bunch of learnings from that, TS 1.3 specs and implementation and goal in between prep transport with draft 23 support, web RTC direct transport, which was actually promoted and created by the folks at Xerox, I think they're here, brought a browser base to Watson deployment. So browser base was a deployment, so BrustDB and GoDBDB as well, with a lot of support from the Xerox guys, who I see in the room as well. We've got concept support that was created by the guys at Sigma Prime in Rust, so attaining the reference guarantee from GoDBDB and porting it over to Rust, as well as the guys from Chinsafe who did the work for JS and for JS and B2B, then they are at the back. Amazing. We also shipped a B2B demon, we have refactored the interfaces and loaded B2B and adopted GoMod. There is an up and coming Bluetooth transport that has been created by a team, a French team that's called Bertie, who are building a decentralized peer-to-peer offline-first message application, and they've got that running on GoDB, shipped in iOS, and of course we've done, we've upgraded any stability and performance fixes across the board. So that is what we've shipped so far in the last few months, the things that actually came to mind. There have been a lot more things that didn't come to mind, so sorry if I did mention some that you think are relevant, and I'm going to talk about what we working on and what's on the roadmap for the next few months. So number one, I would say number one priority, not just for us, but for a lot of projects and a lot of teams across the board is testing that scale. As this has been a recurring topic, whenever I speak to the team, they're pretty confused that they don't, they always ask about, hey, how are you testing IBFS? How are you testing Libby2B at scale? What are the techniques and so on? So when we're actually this has become a bottleneck for us, we want to make sure that every single release of Libby2B and IBFS and other projects that we put out there is well, so that the improvements or the deterioration of each release and each commit is well quantified. And for that, we need a platform which we're calling the Interplanetary Test Ground to be able to create distributed and reproducible tests that hits magnitudes of 100,000 nodes, with simulated network conditions. So this is going to be a platform that is currently in development. We have architected this platform. It is, we're racing towards it. And what we want to make sure is that it's tightly integrated with the engineering life cycle. So basically, it's just no use and having a platform where you have to do things manually every single time, right? So we want for every single commit of Libby2B and IBFS to be subjected to a battery of tests of different kinds, right? So comparative testing, how does this commit compared to a previous commit or to a previous branch? How does this PR deteriorate or improve the status quo in terms of how my node behaves, whatever runtime characteristics, and also in terms of emergent network behavior as a result of deploying that PR in the network of 10,000 nodes, 100,000 nodes, right? We want to be able to do things like chaos testing, interpretability testing. So being able to take, for example, a particular proportion of nodes that are running IBFS or Libby2B version, whatever, 50% that are running this version, 20% that are running this version, and 10% that are running another version and understand how that combination actually plays out in terms of performance. This is what the architecture is looking like. If you want to follow this separate, if you want to track what we're doing, make sure that you watch this rep or IBFS test run. It is right now under the IBFS umbrella, but it's probably going to be moved to the Libby2B umbrella at one point because it's way lower in the stack than IBFS or even a separate top-level project. Another thing that I'm super excited about that we're working actively on is instrumentation. So a lot of teams have asked us for meta observability and essentially the capability to x-ray into what the Libby2B stack is precisely doing in real time. So we currently link the groundwork by taking a data first approach, right? So yeah, it would be awesome to create and help visualizations about things that are having a Libby2B, but really the scalable way to build this is to tap into the inner guts of Libby2B and expose a fire hose of instrumentation data by a standard protocol such that any implementation of Libby2B by adopting a standard protocol would render itself to being visualized and being inspected by a common framework, right? So the next step, so we're focusing on building the fire hose by an introspection protocol that we're drafting. And the next step is to create a binding framework that consumes that data in a browser, creates essentially a reactive state repository on the browser that React D3-driven visualizations can subscribe to and visualize data, whether it's a recording of a slice of time and where we want to get people the ability to move backwards and forwards three times so that you can, if you want to debug a particular situation, you can start up a recording, take a dump, and then load it into the browser and visualize and move through time, as well as watching the activity of a node in real time. So yeah, we plan to release a browser library for developers to compose reusable visualizations and we definitely hope that this will kick-start a catalog of reusable visualizations across the board that are compatible with all Libby2B implementations. And by the way, this project is called Named Phantom Dreads, so if you see those terms, now you know what it's about. So a few of the things that we're going to be working on that we're actually working on are message orientation. So this has been a long-standing missing feature in Libby2B. Yeah. So we're intending for Libby2B to become an entry point. So for Libby2B's entry point to become a factory of stars from which you'll be able to create different kinds of hosts. We're working on that whole bunch in a direct connection upgrade. So we already have UDMP and that PMP port opening support and we have the auto relay and auto-net subsystems that are capable of sensing if you're running behind a map and automatically starting up a connection with a relay and advertising those addresses to the rest of the world so that you can receive in-bound connections, but that is super inefficient. And what we need to do is move to a place where we use that relay connection as an embryonic connection to do signaling between the two between various peers to start to initiate a whole bunching procedure and hopefully be able to whole bunch, right? We're going to be working on robust pervasive fixed point as well with TLS 1.3 and this is important because this combination of protocols is what's used in HTTP 3 as well. And if we make Libby2B run on port 443, this means that we basically have a high chance of being a lot more sensitive to systems than we are. These are a few of the things that we're working on negotiation protocol negotiation. I won't go too deep into this. I have very little time. So multi-side 2.0, if you hear this, there's a bunch of features that are necessary for a 2.0 as well. So they're super high priority for us. We are creating new security channels, TLS 1.3 and noise handshakes. Noise handshakes is going to be using noise pipelines, which uses a combination of optimistic scenarios with abrasive fallbacks when the key has protected on the other end. We're going to be working on TLS 1.3 and all languages. We currently have support for Google and there are some roadblocks in JS and Rust. So we're going to be switching through those and more of a loop. And basically, yeah, so a few more things here to mention like with specific improvements and maturity, pop-up and pollution. So make sure that you come to the concept succession on Wednesday, which is at 2.55 room B10. Because we're going to be talking about some of the things that are coming down the pipe in terms of where this is heading. We're going to be talking about something called TEPISO, which is the future generation of concepts. More evolution, so hardening the DHT, which is a critical thing right now for us. And this is dependent on the test ground. We are aiming to get even better specs. So we're aiming for 100% accurately specced and there's a contributor and there's a figure that's working actively on this. Other topics, CTK, onion routing, repetition, these are things that are ideal every year. We're developing our heads and we hope to flush out over the next few months. Also wanted to showcase what I talked about earlier, the Bluetooth transport in WBTP, which was developed by our friends at Birdty. Unfortunately, it is still closed, so we can't demo it. There's no public access to the code, but that will change hopefully shortly. And that's pretty much all I have for today. So that was super rushed, a lot of content to share. And if you have any questions, make sure to hit me or to pin me around. I'm going to be rowing around. Make sure that we come to the next session that we have about gossip stuff, which is tomorrow at 2.55 and room B10. And make sure if you're excited about the BTP, like we are and a lot of people in this room are, make sure to get involved either by shaping the future, getting everything to the specs, by hacking on meaty things, looking at the dev brands and taking on some of that work. And if you just want to contribute on particular things, then make sure to watch the project levels. So if you have some contact details, if you don't mind being around or if you want to talk a little bit about BTP, make sure to pick me on those highlights. Thank you.