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, and 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 Webbernext. I'm wearing my Webbernext shirt today. So who can tell me the difference between Web 3, Web 3.0, the decentralized web, D webs, dApps, replicated the state machines? Yeah, nobody knows. So that's why I just I was like, I can't rationalize all these different definitions, I'm just going to call it the Webbernext. We're on the Webbernext now, next would be the Webbernext, that's fine. And what that means to me is a couple 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 decentralized 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, empower humans, and foster consent, hence, the Webbernext. [APPLAUSE]. Thank you. Okay, so there's some things that the Webbernext 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. 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 lalala, 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 decentralize 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 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 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 interests, etc. So do we need to guard against that? Maybe not. There's no reason that we need to max out skill points and decentralization 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 when it becomes a vendor sticky, and it becomes a cost control issue, etc? I'm curious, show of hands. Who in here has heard of SGX as a way to solve some blockchain-related problem? All right, 30 is 30% of people. Are you writing your 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 a clover? So the product, but 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 screen shots, we are starting off with making it extremely easy to use the software that you guys and everybody else in the space has 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 how this is basically not really used in any meaningful way between public and the business spheres. Yeah, so we want to help people build Webbernext application, basically. And in doing that, we want to be able to 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, then 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 tool set which right now? 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, since it'll be fun. Did we raise our shilling point? We did. This is where we're shilling, this is the shilling point portion of the 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 and 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, okay. 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 for 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 during 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 lets you search APIs 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 clove, or anything like this. So again, this is all running locally. We provided a few examples like OpenZeppelin, but you can add your own if you want. And EIPs. The EIPs are also searchable in here. So a few examples are- Which ones do you want to try? Try a burn. 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, your C20. 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 these steps ability in a minute? 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, 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- 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 life cycle here. So I found this white paper, I just really enjoy this one for go chain. I don't know if you're familiar with this, but it's 10x more decentralized, and it's 100x faster and a 1000x greater. 10x is really great. Just 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 note in this amazing decentralized network? Apply here to be considered. Awesome, great stuff, so we're not, I mean, there's so many discussions about that. That's not what I'm talking about here. But you might have heard I guess a couple months ago at this point, when Jackson Palmer and Emmond 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 essential. But the one that really caught me, I 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 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 splits between GEF and parity versions to over 80% of the network. So it was just kind of interesting trigger for us to say can we look at some of the 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, so. And the space tends to take a lot more pride in being decentralized, and different metrics, and keeps kind of holding it over each other when they fail to meet some of those metrics. Yep. But- 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. Where in it's not just about having two clients, GEF and Parity, but it is about having multiple clients which are also governed by separate organizations, and that's cool. So across GEF, if you look at the the contributions, and 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 Code Stats. And you can look at all of the underlying data for these, and kind of sort stuff, and you can Contributors and see the actual libraries that they 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 court devs mean, and it's kind of interesting to dig into where the code change, and the code progression comes from. Of somebody who changed the readme in Bitcoin Core a little bit. How to burn. Okay, so there's GEF for you. But I noticed there's one, two, three, four real names that hang out there, there's Parity. Okay, maybe a smidgen more, but really, I mean over half the code for sure is three people. What about Bitcoin? Yeah, you notice there's an interesting trend here. Most of these pirates are circles doughnuts, 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 verses Twitter followers, but it is not a direct inverse relationship. And Zcash, similar. Now, what I did for Zcash also is I diffed 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, 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 we is a touchy number. But it 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. 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 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, so does the project die? Kubernetes certainly, not React has a few major contributors, but any of them is not kind of deciding anything. It's just kind of stood out that Kubernetes has absolutely nothing to do with decentralization. Window login prevention, sure, but they're much better. Yeah, we coul There's no Kubernetes coin, why is that? [LAUGH] they're already decentralized. Yeah. Okay, so remember, it's not just about who writes the code though. And at risk of doing analysis of code contributions, is an implicit agreement that only code contribution matters, and that is not the case, right? 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, right? So the process for this could be initially were thinking about things we're coming up with ideas. Then there's really design processes, your writing specifications. Then you're doing that build step, that entire 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? Or do you have to have a specific operating system? What kind of language is it available in? Where in the world can you run these things? Then how is it deployed? Is it a SaaS thing that you could 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 I'm going back home, right? So how do we handle bugs monitoring usage patterns figuring out what we should build next? It's a long process, and it's not just the DevOps process. It's a full product life cycle, and you could have that same kind of soft power aggregation at any of these points, right? So if we talk about the the brainstorming process, and the obvious question is how many people contributed ideas to this project, right? 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 home, and how are we processing and capturing them? Who feels qualified to be able to share those at new ideas? What tools are you using to capture them? Where are they available? Where do they run? How dependent are we on GitHub? When and where do these brainstorming sessions happen? By the way, every single project that you show a chart about came from GitHub. Yep, good point. 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, how accessible are the kinds of specs that you're creating 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 onto 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? 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 group think. 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 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 where is it hosted? How's 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 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 depths, 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 am I 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, it's a point of centralization in a way. And in a way, a lack of diversity is also itself a part of centralization, because you do not get that heterogeneity. 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 we've been really trying to truly become decentralized. We can only cheat 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 tour where it's great for people in the bubble, but not widely acceptable? We need to think kind of outside that bubble. And remember what the ultimate goal 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. [APPLAUSE] It's cool to see how you lay out the development process, and suggest how we can decentralize that. Do you guys Clover adopt any kind of practice in that development process to make your code development process more decentralized. You want to answer that? I think there's a danger and 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 it's not kind of a rigid process to go through. Because when you once you have kind of a rigid process, it gets a lot easier to lose information and care about the wrong things. Yeah, and I really don't think that it matters that you know 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 come to achieve the ends that they're looking for. We just need to be aware that yeah, 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 like that. Those are things that we need 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 design for it 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?
