 And we're here to discuss a little bit today. We'll show you a little bit of what we've been working on in kind of a fun little new tool that hopefully will be helpful to the community. But also we really just wanted to talk about some of the thought process that we're going through in what it really means to be creating the kind of decentralized quote-unquote applications and that it's not just about the types of networks that we're building, but about the entire type of architecture that we're using and also the processes that we use to create and manage and maintain and extend these kinds of networks. So what are we trying to do here? Are we really trying to drive adoption of a specific protocol? If we're all here because we all agree that we like one kind of protocol, how does that incentivize us to act differently when new things come out? Do we really want to decentralize all the things and put everything on the blockchain? Probably not, hopefully not. If you're in the back, you might not be able to see what I hope we're actually working on, which is building applications that challenge systemic power structures empower humans and foster consent. And honestly, I don't really care how we get there. So, hence the Webernext. I'm wearing my Webernext shirt today. So who can tell me the difference between Web 3, Web 3.0, the decentralized Web, Dwebs, DApps, replicated state machines? Yeah, nobody knows. So that's why I was like, I can't rationalize all these different definitions. I'm just going to call it the Webernext. We're on the Webernext now. Next would be the Webernext. That's fine. And what that means to me is a couple of things. We're trying to build applications where data can be kept close to its point of origin. Trust is not required for most tasks. The low-level protocols might be censorship resistant. Applications may or may not be. You have principles of least privilege throughout the process. There's data portability. There's client interoperability. There's maybe a blockchain where it's helpful and not where it's not helpful. And user experience rivals or exceeds the current Web. We need to be able to challenge the existing business models that have made the centralized Web so powerful and figure out how we can achieve the goals that we're looking for. So if you saw Patrick at Web 3, so we're trying to drive adoption of a specific protocol. No, we are building applications that challenge systemic power structures and power humans and foster consent. Hence the Webernext. Okay, so there's some things that the Webernext can do for you. And here is the way that we're thinking through decentralized architectures. And you might have heard this at Web 3 Summit or at Crypto Springs. I kind of went through it. But the point being that maybe... What's that? I don't know. What does that say? Can you center it? Can you enhance that? Enhance Zoom? That says optional. Oh, shit. Why is that? It turns out that blockchains haven't been around that long and peer-to-peer systems have been around for three decades. And there are plenty of useful tools out there that people aren't using. And if we just keep going, la, la, la, we're here to do blockchain stuff. We fail to learn the lessons that those projects have learned and have tried but not succeeded in overcoming to become used as alternatives to these centralized things. So I think we need to be a little more... test ourselves a little more and say blockchain is not really the answer unless it solves a specific problem for this. But we do have... It's hard to do things which are not centralized. Indeed. So at every layer of the stack, though, there's this potential for points of power aggregation and for what I would consider to be kind of soft centralization to happen and things that we didn't really necessarily intend to happen and things that you can't necessarily code away at the protocol level. So, for example, if all of a sudden all of the research money is going to SGX and it turns out that everyone likes that as a privacy solution and people just happen to converge, which if you're a fancy tech bro, we would call a shelling point. But otherwise, we might just call a lot of people doing a common thing. Then maybe SGX becomes a point of centralization which involves corporate interest, et cetera. So do we need to guard against that? Maybe not. There's no reason that we need to max out skill points into centralization for everything. The point is simply to be aware of how the choices that we're making now have long-term impacts, similarly for heterogeneous cloud kind of deployments of several of these networks. If you're running some sort of permission network and it's within an entire single cloud, what's the long-term impact to that as when it becomes a vendor sticky and it becomes a cost-control issue, et cetera. I'm curious. Sheriff Hans, who in here has heard of SGX as a way to solve some blockchain-related problem. All right. So 30% of people? Are you like writing my name? Would it surprise you to learn that SGX has one signing key for all chips in the world and it's owned by Intel? Exciting times. Okay. So, right. So what are we working on at Clover? So the product with that is under development right now is our view and kind of our pitch to try to make this stuff more relevant to normal humans but also developers who come from both inside and outside of the space. So if you can see on the screenshots, we're starting off with making it extremely easy to use the software that you guys and everybody else in the space has made. But again, it's not limited to blockchain software. It's not a kind of blockchain product. But we are trying to make blockchain-based stacks, ones that are actually being used to solve real problems, especially when it comes to businesses. And Renee was talking about, you know, how this is basically not really used in any meaningful way between public and the business fears. Yeah. So we want to help people build WebRnext applications, basically. And in doing that, we want to be able to dog food those same architectural choices that I was just talking about. And so how can we create a business model that doesn't require us to ask for people's login information every step of the way? How can we make sure that things are faster because they run locally than if they were run via a centralized SaaS service? How can we make people not make trade-offs and want to use this kind of a tool set, which right now, yes, is very developer-centric, but longer term is hopefully for people in general? Yeah. This project is all local and there's no logins. Everything you see, even though it looks like kind of a cloud launcher thing, it's actually just fully local. We're just going to show this quickly because it'll be fun. Did we reach our shilling point? We did. Oh, this is where we're shilling. This is the shilling point portion of the project. Hashtag. Okay. Thank you. Okay. So hopefully this is a useful tool. So Solidity Search. So if you have ever attempted to write smart contracts in Solidity, you may have needed to stop and go Google a specific function to find out what the inputs are so that you could go back and make everything work properly, right? And that takes a couple seconds. You have to go to Google, type things in, find the right thing, click through, figure out if it's right. Right. Yeah. And it turns out a big problem when you're developing software and smart contracts is you keep kind of forgetting what the definitions are. When you have types and named arguments, there's a lot of information communicated just in the types of things. But probably most people in here that are doing smart contracts, if they forget today, they will Google that and then plus Solidity. And maybe it will be the first result. So we thought we'd build a tool that led you search ABIs in which all this information is already encoded and allow you to add kind of your own information to this without it being needed to be sent to any server anywhere or to Clover or anything like this. So again, this is all running locally. We provided a few examples like Open Zeppelin, but you can add your own if you want. The EIPs, too. The EIPs are also searchable in here. So a few examples are... Which ones do you want to see? Try Burn. Oh, I was showing us already. So this is an example of looking for every function that is called Burn. So I can see kind of which contracts in the space that Burn funds. That's the kind of one kind of search. The other probably more common search when you're developing stuff is to type for example, ERC20. I remember some of the methods on this, but I don't remember exactly in which way the arguments go. You can just see the whole interface for the contract. And I'll talk about the extensibility. Yeah, so the second part here shows that you can actually make one Solidity file, import all the libraries that you want to search in this way and compile it with the Solidity compiler and paste it in here. Again, it does not leave your machine. It just is parsed by the page and added to the index. You can also remove the things that we have by default and use totally only your own Solidity APIs. Pretty fun. And so that's at clover.app now. And so it's... Yeah, this is live now. So if you want to check it out, it's clover.app. So that's fun. Okay. So now let's talk about some... What decentralization, quote unquote, means throughout the rest of the development process and lifecycle here. So I found this white paper. I just really enjoyed this one for GoChain. I don't know if you're familiar with this, but it's 10x more decentralized. And it's 100x faster and 1,000x greener. That means it's really good. This sounds amazing. And I was like, how is it so much more decentralized? So then on their FAQ, it's like, how can I become an authoritative node in this amazing decentralized network applied here to be considered? Awesome. Great stuff. So we're not... There's so many discussions about that. That's not what I'm talking about here. You might have heard, I guess, a couple months ago at this point, when Jackson Palmer and Emman Goon decided to put together this arewedecentralizedyet.com site and look at these various metrics by which you could judge some of these different cryptocurrency projects and figure out which ones are the most decentralized. But the one that really caught me, I don't want to talk about any of that point. You can yell about it on Twitter later. But what caught me was the number of clients that are available for these is not higher than three for any. And for most projects is one or two. And now we hear a lot of the time anybody can make a client. If you don't like it, just go build your own. And there's many Bitcoin clients, and there are actually several Ethereum clients as well. But if you look at the statistics of how they're deployed, over 95% of nodes are running the same Bitcoin Core implementation. And in Ethereum, it's split between the geth and parity versions to over 80% of the network. So it was just kind of an interesting trigger for us to say, can we look at some of the code itself and how this is happening in the build process? Because we keep saying, decentralize the development process as though there's this unlimited universal pool of qualified open source developers who are just waiting to be asked to contribute something. And this base tends to take a lot more pride in being decentralized in different metrics and keeps kind of holding it over each other when they fail to meet some of those metrics. Yeah, we poke at each other, right? So, you might have seen yesterday that the Zcash Foundation, which is not the Zcash company, as Zuko would like to remind you, and of which I am a board member on the foundation, so full disclosure. Today is the single most important step for robust and capture-resistant evolution of Zcash in the long run. I thought it was interesting the way that he didn't say, we want to decentralize Zcash. He was very specific in saying that we want to make this a capture-resistant evolution, wherein it's not just about having two clients, a law, a theory, or a guess in parody, but it is about having multiple clients which are also governed by separate organizations. And that's cool. So, across guess, if you look at the contributions, and let me, well, I won't click back at this point, but if you go to clover.app as well, there's another app that's down there that is called CodeStats, and you can look at all of the underlying data for these and kind of sort stuff, and you can click contributors and see the actual libraries that they've contributed to. So, some people might actually work more on importing existing projects or databases into other blockchains as opposed to, say, working on underlying cryptographic primitives, which is fine, we need all things. Some people do test cases, whatever, but there's this whole ego attached to what core devs mean. And it's kind of interesting to dig into where the code change and the code progression comes from. No, a core dev is somebody who changed to readme in Bitcoin Core a little bit. Ouch, burn. Okay. So, there's geth for you, but I noticed there's one, two, three, four real things that kind of names that hang out there. There's parity, okay, maybe a smidge and more, but really, I mean over half the code for sure is like three people. What about Bitcoin? Yeah, you notice there's an interesting trend here. Most of these pies or circles, donuts look basically the same. They have one major contributor, one pretty big one, and then a couple of semi-active ones, and then a bunch of people who have contributed once or changed a few things here and there. And I leave it as an exercise to the user to aggregate or to map these versus Twitter followers, but it is not a direct relationship. There's an inverse relationship. And Zcash. Similar. Now, what I did for Zcash also is I dipped out the portion of the Bitcoin code base that they had used so you can see the actual Zcash portion there, which those are employees of the Zcash company. Does it matter? I don't know, but we need to know who's doing these things. So across all of those, and also just to note when I did Bitcoin, I threw lightning in there as well, so it kind of appears as an additional client, which kind of boosts them a little bit. So I think that across Bitcoin and Ethereum, Zcash, even Cardano, you're seeing like seven different developer, there's seven developers that would account for more than 60% of the code. So if you start from the top of who has the largest percent of change over time, which is a touching number, but has to do with insertions and deletions and stuff, not just overall random commits, that it only takes at maximum seven people to have hit 60% of the code. So. And those are the best ones in the blockchain space. Yeah. Now what about other open source projects that have nothing to do with decentralizing anything? So it's a little bit ironic that Kubernetes and React, some of the most popular and some of the most centralized, or centralized origin in all of the world and all of open source, one coming from Google, obviously, and one coming from Facebook, are far more decentralized in terms of who contributes to the projects and kind of where your risk points are if somebody dies, does the project die, Kubernetes certainly not. React has a few major contributors, but they don't really, any of them have decided anything. So it's just, it kind of stood out that Kubernetes has absolutely nothing to do with decentralization. Vendor log and prevention, sure, but they're much better at it. There's no Kubernetes coin, why is that? They're already decentralized. Yeah. Okay. So remember, so it's not just about who writes the code, though. And at risk of doing analysis of code contributions is an implicit argument that only code contribution matters, and that is not the case. So I wanted to think more about how we get to that point where code is created, but after that how it kind of leaves that mothership and is distributed around the world and becomes kind of installations that we all use. So the process for this could be initially we're thinking about things, we're coming up with ideas, then there's really design processes, you're writing things, and then the other thing we just talked about is really just the build step, then it's who has merge master rights, who's doing the actual commits, then you have how you get the code out into the world and distribute it in a push sense, so that would also include marketing, how you let people know that that product is there for them, and then how people come to you and how they access it. Is it accessible only via web browser? Do you have to have a specific application? And then how is it deployed? Is it a SaaS thing that you don't control? Is it a local thing? Is it in the cloud or not? How is it running? And then how is that reporting happening and then going back home? So how do we handle bugs, monitoring usage patterns, figuring out what we should build next? That's really, it's a long process, and it's not just the DevOps process, it's a full product life cycle, and so if we talk about the brainstorming process, and the obvious question is how many people contributed ideas to this project. But maybe some of the less obvious questions that we should be asking as we go through this are things like how are new ideas solicited and from whom? And how are we processing and capturing them? Who feels qualified to be able to share those new ideas? What tools are we using to capture them? Where are they available? Where do they run? How dependent are we on GitHub? What kind of reception do disruptive ideas receive from the community when they're proposed? Whose opinion is able to bless or kill an idea? I mean, I know it's a meritocracy and the good ideas always win. And in which languages are the ideas shared, right? And then moving up to the design process, like how accessible are the kinds of specs that you're creating to other audiences? Are they presented in languages or are they distributed to other audiences? Are they presented in language that they'll understand? How is feedback collected? Who's deciding if we're ready to move on to this? And how similar in perspective are the various contributors to the actual design? Do they all use the same mathy languages? Do they all want to write something in latex that isn't necessarily accessible to some other people? How can we kind of, this is where it turns into sounding like diversity and inclusion? But it's not really, it's about finding how to create a more robust design process that doesn't become centralized around any specific kind of groupthink. Then the build process we already talked about with all of those code stats, but it's easy to say how many people contributed to the code base, but more important is probably how many people made those significant outsize contributions. How specialized are some of the skill sets that you need in order to make a significant contribution? And all projects are not created equal there. How many different working implementations, not just hobby projects, are there? How many of those individuals do you want to aggregate up to the same corporate entity? How welcoming are we to newbies? And how well documented is the code? We could go on and on and on, but we just need to do a better job of thinking through what these things are. And then I kind of bundled all these ones at the top here. But you know, where is it hosted? How is it phoning home? All of the privacy issues that you have. Where are the bottlenecks in this process? And this is where I think it's a lot easier for us to call out third-party entities and say, oh, well you own that. You push that application out to us, and because of that it's centralized. But really, especially if you look at most of the DApps, there's really only one way, one or two ways to access them, and not a lot of people are spending their free time, even if APIs are published, to go out and build competing implementations. So to kind of wrap up here, how might these soft dependencies impact the Ethereum community and also other cryptocurrency and decentralized projects at large? Well, every single one of the points that you just mentioned is a point of centralization in a way, and in a way a lack of diversity is also itself a point of centralization because you do not get that heterogeneosity. And so our takeaway for you is try to evaluate the projects that you're currently using in the space and the project that you're developing, and see where these fault lines are because if you're really trying to truly become decentralized, we can only wait for so long before somebody kind of calls us out on it actually not being decentralized. And ultimately, what are we trying to build? Is it about maxing out those decentralized stats and competing stats, and if we do that do we not run the risk of ending up with either a year of the Linux desktop problem for these applications, or possibly that it stays something like TOR where it's great for people in the bubble but not widely acceptable? We need to think kind of outside that bubble there is, which is to build these kind of applications that allow us to challenge existing power structures and foster human consent. So, thank you. It's cool to see how you lay out the development process and suggest how we can decentralize that. Do you guys at Clover adopt any kind of practice in that development process to make your code development process more decentralized? Yeah. I think there's a danger in kind of adopting a methodology versus keeping these things in mind and evaluating them when new information meets you, so we do think about these things all the time but it's not kind of a rigid process to go through, because once you have kind of a rigid process it gets a lot easier to lose information and care about the wrong things. And I really don't think that it matters that a single company or even a small group of individuals are putting tools out there if those tools are allowing the people that use them to achieve the ends that they're looking for. We just need to be aware that if those people get hit by a bus or that company implodes or they just suddenly decide that Do No Evil was a bad slogan and then we're stuck with it, those are things that the community needs to inoculate itself for. And hopefully, theoretically, market forces are supposed to take care of that but it would be probably a better idea to just sort of get a little bit of the support up front. And it's not really easy to say how we live up in the tools that we showed, for example to kind of being decentralized. Of course, it's hosted centrally but you could take those JavaScript files and HTML file, you could put it somewhere else. So is that decentralized? It's open. Awesome. I think that's our time unfortunately. Thank you, Amber and Patrick. Thanks. Thank you.