Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Alexis Sellier & Eleftherios Diakomichalis: Radicle – The Decentralized Platform for Code Collaboration

Episode Date: February 10, 2021

Radicle is a decentralized platform for code collaboration. It's built on Git and is an open-source decentralized alternative to platforms like GitHub. Tools like Radicle are an essential component of the decentralized technology stack and will enable DAOs to commit code through governance. Co-founders Alexis Sellier & Eleftherios Diakomichalis joined us to chat about why they felt it was important to create Radicle and how it fits into the DAO ecosystem with a more accessible governance system of code.Topics covered in this episode:- What Radicle is and the vision they are pursuing- After both working on Soundcloud, the lessons that were carried over to this project- The Cathedral vs Bazaar model- Git usage with the tool- The technical architecture of Radicle- The other differences between Radicle and GitHub- Storage and replicating solutions between peers- How Radicle promotes open source sustainability- Ethereum integration with the toolEpisode links: - [Radicle website](https://radicle.xyz/)- [Radicle docs](https://docs.radicle.xyz/docs/what-is-radicle.html)- [Radicle on Twitter](https://twitter.com/radicle)- [Alexis on Twitter](https://twitter.com/cloudhead)- [Eleftherios on Twitter](https://twitter.com/lftherios)Sponsors: - 1inch: Discover the best rates and most efficient swapping routes across leading DEXes. Optimize on gas cost and execute DeFi trades faster with 1inch V2 - https://epicenter.rocks/1inchThis episode is hosted by Brian Fabian Crain & Sunny Aggarwal. Show notes and listening options: [epicenter.tv/378](https://epicenter.tv/378)

This is Epicenter, Episode 378 with guests, Alexis Celiae, and Elefterios, Diacomacalos. Hi, I'm Sebastian Quirotio, and you're listening to Epicenter, the podcast where you interview crypto founders, builders, and thought leaders. On this show, we dive deep to learn how things work at a technical level, and we fly high to understand visionary concepts and long-term trends. As you like Epicenter, the best way to support us is to leave your review on Apple podcasts. If you're on a Mac or iOS device, the easiest way to do that is to go to Epicenter. slash Apple. And I'm speaking specifically to all of you who have started listening to the show in the last couple of months. With the bull market, our audience has gone up, and that tells me that there's a lot of new

listeners. So do us a favor and leave a review on Apple Podcasts. If you haven't subscribed yet, you can do that on Apple, Spotify, or wherever you listen. Today our guests are Alexis Celier and Elefterios Diacomicalis. They are the co-founders of Radical. Radical is a new platform that is changing the way that we collaborate around code. Right now, if you're a developer, there's a pretty good chance you're using Git and GitHub. And GitHub is a centralized company. It's actually owned by Microsoft since the last little while. And one of the main criticisms of GitHub is that it is amassing all of this source code from public repos and also private repos. And that is a huge value for, you know, the owners of GitHub. Radical aims to create a decentralized version of

this. And of course, that has some really interesting implications around how the system is structured and how communities come together to decide what is the canonical repo for a project. The other cool thing about radical is that it closes the gap between decentralized governance and the canonical repo for a project. So take any blockchain that has a governance process built in for updating code, like Cosmos, for example. People make preparations. People make proposals there. The code gets voted about whether or not it will make it into the hub, but someone still has to commit that code to the Cosmos repository. Now, projects have figured out like their own ways and they've come together on their own ways to make sure that this is

somewhat decentralized. But with Radical, you could actually connect this governance process directly to the process by which the repo gets updated and the code commits get made. So this opens up a lot of potential, I think, for decentralized governance around not only blockchain projects, but just general code collaboration to emerge. Many of you have been using one-inch. In fact, we've gotten a lot of positive feedback about this sponsor, and it's no surprise because they're a great product. It's my go-to-dex aggregator. I use it anytime I need to make a swap because I know that I'm getting the best price across Dexes and AMMs. Definitely check them out. You can do that at epicenter.rocks slash one inch that lets them know that we sent you.

And with that, here's our conversation with Alexis Celiae and Eleftherios Diacomicalis. We're here today with Ellie and Alexis from Radical. I've known him for a long time, actually. Alexis briefly worked for a tendament in, that must have been 2017, I think. briefly and then immediately started working on on Radical at the time it was called the Westcoigne and yeah

so I've sort of followed this project on for a long time just this claim that I invested in the project kind of back then so it's very exciting to see kind of like how far it's come and now you know there's actually something out there that allows people to collaborate on code

and you know we're going to go a lot into what that means and what sort of vision for radical is. So thanks so much for joining us. Thank you for having us. Yeah, thank you. So, yeah, let's start there. What is radical and what's the vision you guys are pursuing? Yeah, Radical is a new kind of code collaboration network that is designed with certain

goals in mind. It's designed to be truly sovereign. It uses peer-to-peer infrastructure behind the scene. It's also designed with security in mind. And then finally, it brings together concepts like centralized organizations, you know, value flows, things that we see a lot in the blockchain ecosystem. It brings some of those closer to the code collaboration experience. And maybe just to kind of wrap our heads around a little bit,

like why is it important to have code collaboration, done in a novel way, in a decentralized way? What's wrong with the existing ways that's done? We see a number of problems with centralized code collaboration providers. The biggest problem in a hot topic right now in the world is the problem of user and project censorship. Unfortunately, most of the existing centralized providers basically have to limit usage to certain areas like Iran, Crimea.

like, you know, there are a number of places in the world. So when we're thinking about open shores being truly open, you immediately start to realize that there are all of these different arbitrary, you know, walls that come into play and that limit, basically, the openness of our open shores infrastructure. So that's the first problem. Additionally, many of the centralized forges have not been designed with security in mind. You know, we can zoom in on that quite a lot.

But the example that I would give there is that a few months ago, there was this significant hack on Twitter, where some of the most high-profile accounts were compromised, and then I think the attacker was basically tweeting some kind of Bitcoin, like Send Me Bitcoins type of link. So imagine similar attacks on your code collaboration infrastructure where someone potentially inject something in a very significant code base, and you know, you as the maintainer of that project,

potentially you wouldn't even be able to notice, simply because a lot of, you know, commits on GitHub go unsigned, for example. And then additionally, you have, like, when we're looking at decentralized forges, there are a number of attacks that are being pulled off on the social artifacts, not only on the code side of things.

So secure code collaboration and distribution of code basis. We think that it's a fundamental problem with centralized infrastructure. So censorship one, security, second. And then additionally, you have a number of other problems like obviously vendor login. Most of these platforms today provide, they speak Git, so they actually operate based on an open protocol, but they haven't engineered a number of things around those, the most common being

social collaboration, and these obviously are locked into their own platforms. These are the three things that we believe are really relevant for everyone. And then additionally, you have a number of problems that actually are specific to the decentralized world. So the decentralized world, especially last year, we saw the emergence of a lot of DAOs, right? These are groups of people that actually go through the process of coordination and, you know, the pain of coordination many times to actually align incentives. And what happens there is that actually, like, when they, all of them usually, you know, have some kind of code. repository, like where they store the code. Most of these things are today on GitHub.

And unfortunately, there they actually, they have to go through the classic admin flow of some of the centralized providers where, you know, it doesn't matter if you are now. It doesn't matter if you have all of these very sophisticated coordination schemes. You need one admin that actually will have overarching power over over the stats of the code base. Or you might, like, you can have multiple ones, but actually in many ways this even worse. given that each and every one of them now has a lot of power over the community. So what radical allows there is it allows decentralized organizations, decentralized applications to control software reports trustlessly,

which we think is a very relevant point for them. Finally, there is an opportunity as well. Like today, most developers still struggle with the problem of open trust sustainability. This has been a hot topic on the web for the last few years. we personally think that blockchain enable new experiments around value flow and what we're looking to do with radicalists to actually bring them closer to the code collaboration experience

and hopefully enable more humans to sustain their open source work and contribute to the comments. So yeah, a number of topics, but censorship, security, vendor looking, decentralized ownership and then sustainability. These are the five problems that we see with centralized code collaboration platforms. Cool. So you guys were both at SoundCloud at one point and I think SoundCloud, you know, I don't know as

much as you about this, but I think SoundCloud also had this kind of vision around, you know, collaborating and creating music, distributing music and kind of like a different approach that was maybe a bit more like open and decentralized. In the end, it seems like they didn't really succeed there and you know you had maybe more closed platforms like Spotify, Apple Music, etc. that ended up sort of winning. I don't know if that assessment's right. But I'm curious, what are your lessons from your time at SoundCloud or how that experiment has played out that has kind of, you know, informed your approach to a radical? Yeah. That's a great question actually.

And what's so interesting is that many of us that joined a lot of the Web 2.0 platforms early on, you know, the vision and the excitement was coming again from, you know, disintermediation, right? It's the same story. Like, you basically, you were hoping in the music industry, like back then, you know, like we were hoping that we will be able to actually develop platforms, experiences, products, that will enable creators to actually own more of the creative process. And as you said, I think with SoundCloud, we really succeeded culturally. I believe that SoundCloud had like a really significant impact in the music industry,

like really normalized things that were not, you know, the music industry didn't want to look at like they were like, you know, like I don't remember what was the official term, but, you know, it was kind of gray, like, you know, like gray type of content specifically think about DJ mixes, covers, mass ups, all of those things that now we believe that actually are normalized. But obviously we think that like it failed, SoundCloud failed to actually, you know, truly like realize this disintermediation, right? So, you know, creators today are still customers of SoundCloud. They're not owners, you know, SoundCloud. And this is where crypto and the Web 3 is very, very interesting for us, simply because it has this promise of community-owned and operated networks where you, you know, you know that no platform can actually get extracted against you. you can be the platform, right?

So, yeah, that's one thing that we really, you know, keep close to our hearts. And, you know, it's the North Star for some of the work that we're doing with Radical. How can we actually enable developers to have that power over the tools they use every day? One inch is a decentralized exchange aggregator that sources liquidity from the top dexes and the AMMs to save you money and time on swaps. One inch finds the best possible trading paths across over 20 support. recorded liquidity protocols and splits them up across multiple market depths. I started using one inch

last summer and since then it's become my go-to aggregator. I use it every time I need to make a swap. They recently launched V2, which has a brand new API. It greatly improves their routing algorithm. And my favorite part about the V2 is the new UI. It's super clean and easy to use. These improvements ensure that you get the best rates on your swaps with the lowest possible response time. So the next time you need to make a swap, forget about getting the best rate or optimizing your gas fees, make it easy on yourself. Just use one inch. And you can let them know that we sent you by go to epicenter.rocks slash one inch. That's one inch. We'd like to thank one inch for their support of the podcast.

So to dive in a bit now into like, you know, some of the features and visions that you talked about. So I guess my first question is when it comes to things like censorship resistance, what's the need to build like this as a protocol when, you know, rather than just promoting more competition at the service provider level. So, you know, GitHub is still the dominant platform, but there's also other like competition from, you know, other products like GitLab and Source Forge. And especially when it comes to like, you know, GitLab is open source and you can self-host it if you want. So what does radical provide that like a self-hosted system would not? So one of the problems with having sort of relying on multiple competitors or multiple platforms as a as a way to reduce platform risk is that a lot of these platforms, at least the famous ones, are in the same jurisdictions, right? And so they actually don't necessarily behave differently.

What I mean is if you have like a sort of like a political issue, for example, like we're seeing recently with, you know, geo-blocking or embargoes and things like that, it's very likely that all of the platforms will actually behave the same way, right? They will take the same steps, block the same users. And so there isn't really any benefit in jumping from one platform to the other because you essentially end up in the same exact situation. And it's the same thing with a, you know, hosting or like cloud providers, et cetera, because they essentially end up all doing the same things and censoring exactly the same users in the end. Yeah, and to add on that, like if you really look at how these platforms are emerging and evolving, you know, what started as a place for hosting Git repos now has become the place where my life's work, you know, is and lives, right?

Not only that, like now where this whole space is going, is that this is where also where I make my income with things like GitHub sponsors, right? So you basically like, you know, take some of these problems that start as like, oh, my contribution is blocked or my account is blocked. And, you know, like looking at the trend and are reliant on some of the systems, you realize that in the future you might be completely canceled because one of these platforms basically decided that they do not want to accept contribution from someone that visited Iran,

but also your salary might be canceled. You know, and like, you know, you have all of these systemic, systemic risks that we don't, we really do not think that the Web 2.0 was designed, you know, with those in mind. So that's one thing. Yeah. And then on your second, on the second part of your question about self-hosted instances, that's actually very interesting because, indeed, there are a number of providers. There's GitHub, GitLab, Git.

Like, you know, SourceHad. There are many providers, all of them, you know, speak Git. And then many of them offer self-hosted instances. But what's really going on is that, you know, you are almost like confronted with this decision that either I go for convenience and connectivity, right? Either I'm on the community edition of GitHub and anyone can find me, or I isolate, right, and I have control by running a self-hosted instance that basically, you know, no other, like, you know, actor usually, you know,

like can access. You don't have the network effects, discoverability and all of that. So Radical basically tries to find a place in the middle, where you do not need to compromise your connectivity in order for you to actually be self-sovereign, right? And yeah, and that's what we think that we're adding to the mix. Yeah, maybe to add to that, there's no global identity layer essentially. If you go with self-hosted instance,

your contributors are going to have to create a new account every time. So there's really no social effects or network effects there. Yeah, and maybe to add one more thing because this is an interesting one, There are attempts for a federated Git, like basically, like, yeah, you would say a federated Git network. If you search for that, you will find a number of attempts there. You know, none of them has actually materialized yet. But even if they do, the problem we see with federated systems is that you always rely on,

you know, like, okay, pick your cis admin. Great. Okay, yes, I can move away from that instance. But, you know, your obsec is as good as, you know, your, you know, the practices. of your cis admin and and also like based on evidence like in the past evidence we see that again you have the same centralization tendencies where you know one one instance will become you know the canonical one and then you have again the same the same issues with you know power and trust so we really think that peer-to-preas systems actually are an answer to this problem and they are a much

more preferred way to approach that and that's why radical is engineered as one so one of the things that, like, I think is also very different is not only are you guys, like, kind of focused on, like, the tooling, but also in this, like, larger process of open source development. And so you guys are very, like, you know, a lot throughout your documentation, you always bring up this cathedral versus a bizarre model. Could you maybe talk a little bit about that and then how that shapes the, uh, what you guys are building?

Yeah. So the cathedral and the bazaar was an essay by Eric Craven, if I'm not mistaken, where he talks about two kinds of development models, right? One is the cathedral model where essentially kind of have a sort of centralization around the repository and everyone kind of pushes and pulls from that repo and some of the now less used version control systems like SVN were built around that model, right? And then the bizarre model is very different. It's much more peer-to-peer,

and you essentially don't really have a sort of canonical master or repository. Instead, you have many, and they operate in a more peer-to-peer way, as I said. And Git was built for that model, right? And they obviously have pros and cons. if we look at GitHub, that's definitely promoting the cathedral model because you have a single repository and you manage permissions, right? Like an access control list, team members can push and pull there and there's an admin, and that's the cathedral model.

I guess the advantages, obviously, are that for small projects. It's a lot easier to manage, right, because you have one place to look for, to pull from, to download from, and to manage, right? It's very easy to see what the latest commit is in such a repository. But of course you have issues with that. For example, when it comes to scaling, so to give a different example, the Linux kernel is managed in more of the bizarre model

where you have a sort of hierarchy of maintainers that fetch and pull code from each. other all the way up to Linus who you know has a sort of trusted set of maintainers he pulls code from and merges right and so this this model scales a lot better for that reason but of course it can be a little bit daunting to approach in terms of a radical since we were designing a peer-to-peer system we found that the bizarre model was a much more natural fit essentially and trying to trying to shoehorn the sort of centralized repo approach of GitHub would be very difficult.

But one thing to keep in mind is for, in the case of a single maintainer, sorry, so if you have a repository with only one maintainer, there really is no big difference, right? Because you do have a canonical place to pull code from. And the maintainer is the only one who pushes to that repository, right? So in that case, it's the same. It gets more complicated when you have multiple maintainers and bigger projects. There, you're sort of forced to appoint a sort of lead and to say, like, okay, this is, this maintainer will hold the latest or the canonical changes or state, whereas these

other maintainers are going to, you know, work with staging branches or whatever it is. So you have to have some kind of out-of-ban organization there. So do you think that the tooling is a product of culture or is it more an input into culture? So what I mean by that is, you know, like you said, Git can be used in this very bizarre or cathedral model. And then the tools like GitHub kind of nudge people towards using a more cathedral-esque model. Do you think GitHub was designed this way because the culture and users' demands? the cathedral model, or was it like pushing people towards that? And then if you build this tooling for people to develop in a more bizarre-like model,

do you think that will influence the culture and get more people and open source software to be developed in such a way? There's definitely a little bit of both. I think GitHub did have a huge influence on the way software is developed. because even though, you know, it's not like the cathedral model was completely new, right? It was very much the way things were working at the time. And perhaps you could say GitHub popularized it. But I think in terms of radical and the bizarre model, it's definitely a model that is today a lot less popular.

And that confuses some people. and if we're going to be successful with a project, we're going to have to make that model more accessible, right? I think that goes without saying, because there's something about the simplicity of GitHub where you have one place to look for changes, one place to manage permissions and manage issues and everything. This is, for people who are new to code collaboration,

this is a lot easier, right, to explain and to work with. So it's going to take a little bit of learning and a bit of adapting from a users. But I think we can influence things in that direction. So I'm wondering if you can explore like a little, let's just explain this a little bit more. I mean, I understand the guitar model on a high level. But like, let's say now you had a project that was developing in this more bizarre, like, way. Like, what does this actually, like, look like? And what are some of the tangible differences in terms of, you know,

maybe how software is developed, how it's managed, how it's governed, from following that different model? Yeah, sure. I can give you an example. So maybe one way to think about it is that on GitHub, you have a project that is not necessarily attached to a single user. It may be under a user account, but multiple users have right access to that project, right? In Radical, for any given repository, there's only one user would write access to it.

Okay, so the first thing is it's closer to what we call the GitHub open source model where you have to fork a repository to contribute to it via IPR, right? So currently, so today already on GitHub, if you're working on open source, or contributing to an open source project, you don't ask for right access, right? What you do is you fork the project, you make your changes, and then you open a pull request, and then the maintainer can merge those changes.

So radical is a lot closer to that, but you can have multiple maintainers who can merge changes, right? So one of the core differences is that you have to settle on what you want to be the canonical repository. And for something like Linux, as I mentioned, Linus' kernel tree is the canonical one, right? And everyone knows this. When you have a Linux distribution like Arch Linux or Red Hat, they will usually pull from his tree, source tree, to release a new version of the operating system.

And this is known. And the same thing applies for radicals. So you have to figure this out within the table. us out within the team, within the community for any given project that a certain user's source tree is the one that is considered canonical. That is the main difference. Now, we are working, for instance, and we're going to talk about this later, I think, but about how Ethereum, for instance, could help with figuring out a canonical tree, right? Because in the Ethereum world, you have a global database essentially.

And there you can mimic some of GitHub's behavior where you can say, okay, this is this user, this user's tree is the canonical one. This is where you push and pull from, right? But yeah, in the pure peer-to-peer model, this is something that needs to be decided per project, essentially. So I'm still having some trouble understanding then, what's the difference?

If there's still one canonical version of the repo, which is, you know, whether it's Linus is. What's actually the tangible difference then? Like, is it just that there's more, you know, there's almost like submasters where like, you know, instead of like merging everything to like the main master branch, you know, we have a bunch of like sub branches and we're merging to those. And then eventually those,

it's more of a tree rather than like, you know, a single hub and spoke system. But like I'm not fully understanding what makes this that much less hierarchical. than traditional model let's use today? So maybe one way to think about it, that could be helpful, is that in Radical a project, which is the kind of unit of collaboration in GitHub, it's called a repo. We call it a project. And Radical a project is not owned by a user.

So this is kind of, so on GitHub, if you look at, you know, whatever, the Bitcoin project, it's under the Bitcoin organization, right? So it's owned by the Bitcoin organization. In Radical, a project like Bitcoin would be sort of self-sovereign in a sense. It wouldn't have an owner per se. It wouldn't be under a certain user account necessarily. What it would have is one or more maintainers. And you could say, oh, if there's one maintainer, it's kind of like the owner, right?

which that could work as I said but now let's say there's 12 maintainers right you have this project with a bunch of maintainers there is no immediate indication of who owns this or where you can find it basically so it's it's a subtle difference

but it means that projects essentially are sort of cell standing or like free floating could say and to add on that for like maybe the less technical users. So on GitHub, you land and immediately have this concept of main or master, right? Which you know, this is like the state of things right now. And, you know, GitHub basically makes that very easy for you. In radical, every project actually needs to go through this

coordination phase of like agreeing on what's the canonical state of things for a newcomer. You know, you land on a project. You are like, okay, how do I know what is, you know, the latest here? So there's this coordination step that obviously, you know, we try to make this very simple for you. So, you know, imagine like a little label that says like Sonny's branch is the canonical branch here, right? So that's one difference. The second difference with something like GitHub is that on GitHub you land on the project and then you can see basically like you can see all branches, right, because they have a global database behind things. In Radical, you need to be more explicit about that.

You need to be more explicitly request on the peer-to-peer network that I'm interested in Brian's brand and Sani's branch around this project. And of course, again, you know, there are ways where we can make this a lot simpler for you by using something that we call seed nodes, which are kind of like pinning nodes

and IPFS or, you know. But yeah, these are two immediate differences that, you know, no master remain, you need to coordinate on a project basis. And then the second thing is that not access to all the data. This is a period of great network, so you need to be explicit about which views

within the project you actually want to replicate. So we've kind of touched it in a few ways now, right? You mentioned in the beginning, okay, this idea of allowing decentralized organizations controlling software repos, you know, we now kind of talked about, you know, different branches having, you know, which one's a canonical one.

Also the idea of like maintainers, right, the role maintainers came up. I mean, for me, probably, you know, the place where this topic became most, came most of my attention was like years ago in Bitcoin, there was a lot of controversy about, you know, where the project should go. And, you know, I think, for example, the block size was one thing. And actually a lot of that controversy then ended up playing. around, you know, what kind of things get merged into the core Bitcoin repo.

Who's the maintainer of that, right? And then you had certain people being removed there. You ended up having people making forks. And, you know, but then, you of course, you had the shelling point around, you know, there is this one GitHub repo that people know as the Bitcoin GitHub repo. So if I just fork it, then it's very hard to get people to go around that, right? So you ended up having this almost accidental kind of point of control over Bitcoin that ended up being with decentralized software and the maintainers there. So I'm curious if you can like expand a little bit, talk a little bit about that and talk a little bit about how, you know, how in a sort of radical based development world this would look like.

Yeah, interesting. Yeah, so Bitcoin basically, I think it was a couple of years ago, it forked into Bitcoin Cash, right? And then Bitcoin SV a little bit later, that was a fork of Bitcoin Cash. And now there's three separate, at least three separate instances of the project with different maintainership and goals and everything. I think one of the important things there is to differentiate between the different kinds of forks that exist in software collaboration, right? There's a different intent if you're trying, if you're forking with the intent of merging those changes back in versus forking with the intent of never merging the changes back in because you have diverging goals, right? And so those were definitely

the latter. Whereas on GitHub, when you create a fork of something, it's also used as a way to merge changes back in to upstream, right? So in the radical world, we have something called a project ID for each project, and these are, it's essentially a hash of some metadata around the project. And if you are intending to make changes to a project that you intend to be merged back in, the kind of fork you would create would preserve the original project ID, right? So you would essentially create a, you know, just a new branch on the same project, publish that, and then you would intend that to be merged back in. If on the other hand, you're intending to do a fork like Bitcoin Cash, you would actually create a completely new project identity

for that, right? It could have the same code, the same history, but its identity would be different. The hash would be different. The maintainer would be different. The description of the project might be different. And so it would have a different identity, and then these projects could no longer be merged back into one, essentially, through the default radical tooling, of course. So I think beyond that, actually, there's not that much difference with what happened on GitHub.

What I mean is in both cases, you have a bunch of maintainers that are sort of in control of a project or repository, and in both cases, there is either an intent to diverge or to converge towards the same goal. I think the only thing may be worth saying that is interesting with radical is the maintenance of that project identity, right? So it's essentially a file which has the project description, the list of maintainers, and a bunch of other data. the maintenance of that file goes through a quorum, so a vote in a way. So if you have more than one maintainer for a project, let's say you have three maintainers, then to change the project identity, you need two signatures, two out of three signatures,

in that case, right? And this is something that perhaps would be helpful in this situation because you would have a clear governance model around that at least compared to GitHub where you have a sort of superadmin that can remove other admins and can never be removed. And then you have a bunch of maintainers or admins who have almost all of the power of the super admin except the ability to remove the super admin. And so there you have a less well-defined structure, I would say, compared to radical. Yeah, and maybe Brian to add on that, and I'm actually glad I'm glad you asked because as of two weeks ago, one of the core maintainers of Bitcoin Core basically started experimenting with Radical.

So actually, if you go on Radical, you will be able to find the Bitcoin Core you both day. Yeah, like, and he also wrote a blog post about how they planning on basically decentralizing their process. And they mentioned a number of steps there. And they also, you know, talk about Radical. and specifically they talk a lot more about this whole idea of vendor looking like you know specifically like them mentioning the fact of like hey we can like we can jump to the next platform you know but like you know now basically we have all of our social arts facts you know locked locked in in that platform so so playing the bitcoin core scenario like you know what would bitcoin core win from being on radical number one you know

they would rely on a peer-to-peer network. They won't have to rely on any company for the distribution of the Bitcoin Quarible. This is a truly peer-to-peer network, right? So you have basically global, like, you have better availability around that. That's one thing. And then the second thing you have is that in Radical,

basically the social art facts live within the Git object, right? So that's what we mean on the website when we're basically talking about build on open protocols, not platforms, including your social artifacts, basically no corporation owns them. They can actually move, like, they can move them away without actually having to, you know, worry about that. So that's the second thing that they immediately win. And then, you know, basically censorship comes with that.

And then finally, the thing that Alexi mentioned, which in Radical, you have this delegation scheme around repo. So for certain critical operations, you know, you have to go through some kind of, you know, like vote, you can think of it as a multi-sig. You know, you can think of it in many ways. But that is much more secure rather than actually, oh, it happened that I was the first one that created this project. I'm the super admin of that now basically like, you know, I might go rogue, which happened, for example, on, I think the Reddit community.

Like, there's a famous story around Bitcoin there where, you know, on the fork, they decided to keep the name, the ceiling point, but actually changed the content, right? So, you know, this type of things, basically, you can deal much better with them in Radical. So when it comes to the social stuff, there have been like past systems which have like incorporated social features into the Git repo itself rather than this like external thing. Are you guys making use of some of the existing ones or is this something you guys have like developed from scratch? And if so, is there anything new that's not in the like, you know, existing solutions? Yeah.

So we're in the process of developing these right now, and the two main ones, obviously, are pull requests or merge requests, and the other is issues, right? In terms of issues, which we're going to work on a little bit later, there is one very good solution that allows issues to be managed within Git, called Git bug, right? It's a tool, I think, built-in Go, and it essentially stores issues as Git Notes,

from what I remember, which is a native feature of Git. So it's very possible that we end up adopting that and building a front end on top of it because our replication system just replicates the Git tree, right? It doesn't really care what objects are in there. It will just replicate whatever is necessary. And so we would essentially get that for free. in terms of pull requests or our equivalent,

the very basic way of doing that is really just a way to signal that a branch you've created is meant to be merged back in, right? So it's really just branch plus intent of merging, right? And for that, we have our own system that we're working on. That is really, really simple, actually. What comes after that is code review, of course, and that's a massive undertaking.

You know, GitHub has been working on their code review, on their code review flow for years, and new features come out every month or every year or whatever. So that's a more complicated one. We don't have any plans on using an existing system yet, although we are taking some inspiration from Garrett, namely in terms of how the code is structured, how the code is proposed to be,

merged, et cetera, because GitHub does have some limitations there in terms of the history of changes that are often lost or overwritten when there's a force push, for example. So we are trying to make some improvements there, but otherwise it's looking like we're going to have to create our own system for that. I did want to actually ask just a sort of follow up to the previous thing. So like today, like you have a lot of new blockchains that have on-chain. governance or people create like DAW or so the you know these organisms like kind of collectives on chain and you know as you guys pointed out before often there's like some sort of code repo

generally on GitHub right that sort of manages this code that's used by this on chain project and then of course you do have to challenge right that let's say there is some kind of you know to give cosmos as an example right there's some sort of like cosmos governance thing on like oh do this with, you make this kind of change, but then the software repos actually coupled from that. And, you know, the on-chain governance can't enforce, you know, the change on GitHub. So how is that going to work with Radical? And can you, like, to what extent can you couple those things so that it's really kind of the on-chain governance that directly controls, you know, changes to the software repo?

And is that actually desirable? Yeah. So that's a great question. Maybe I think that's a good segue to basically say a few words about the radical architecture because I don't think we said anything yet. So radical is three components conceptually. There is the peer-to-peer network, which is a peer-to-peer network organized around Git. And the main innovation we're bringing to the mix is introducing the social overlay around

Git repos that looks a lot like Secure Scuttle, but I think you had Dominic here maybe a few months or years ago. So there's a peer-to-beer network that you actually use for most of your code collaboration needs. You do not need to interact with the blockchain, you know, like you don't need to hold any tokens or anything like that. You know, it's available for everyone for free, right? And this is where, you know, you basically live most of the time.

So that's layer one. Layer two is basically clients, right? And what we've done already is we developed a client that we call Upstream that acts as the main user interface. You download this locally, and we already support Mac and Linux. And we're actually spending quite a lot of time on try to build beautiful experiences around code collaboration. We realized especially for new developers, this is very important,

and GitHub has been very, you know, like impactful in that front. So that's the second layer. And then the third layer is what we call our theory. integration, the Ethereum layer. And this is an opt-in layer. You do not need to use this if you don't want to. And there are a lot of developers that actually do not like blockchain. Some of them do not like Ethereum, right?

Like you have the Maxi Wars and all of that. But what the blockchain gives us, fundamentally, it gives us three things. The one thing that it gives us is canonicity, right? So you can think of the blockchain as a global database, right? And canonicity is very important for things like global names, for example, and discoverability, right? Like, you know, GitHub has been so significant, like, because of how easy it is to pass repos around and all of that. So we're covering that through a blockchain and we're actually developing a registrar that is compatible with the Ethereum name service, ENS. So that's one thing that we believe that will actually, you know, help a lot with discoverability and network effects.

The second thing is we're actually leveraging all the nice tooling that the theorem has around decentralized autonomous organizations or governance, right? So we mentioned before that on the peer-to-peer layer, you already have a method to coordinate based on a quorum, but that's actually quite limited. If you want more sophisticated coordination schemes, then you can actually use like all of existing DAO frameworks on Ethereum to coordinate around what's the canonical take-off of your repo. So that's the second thing.

And then the third thing that we really, we use Ethereum for is specifically around value flows. When we started the project, you know, we had two goals. One goal was develop resilient infrastructure for software developers. And then the second goal was to actually enable more developers to make a living for their open source work. And there what we're trying to do is we try to basically use cryptocurrencies. in order to basically help developers keep contributing to the commons. And we have a number of experiences that come there.

But the Ethereum layer is actually completely opt-in, right? So when you're thinking about the radical architecture, these are the three things. Now, moving to your question about governance. So we see this a lot from our users already. This is one of the most requested features we have, which is I have a DAO, you know, I'm this like well-known DFI protocol.

I have a DAO. And I want to coordinate on what's the canonical state of things here through my doubt. I do not want to actually trust an admin on GitHub. And we've been working with a number of teams that have been showing us what to do. And it's actually quite fascinating, actually, you know, what they do today. Like many of them maintain multiple GitHub organizations that pretty much mirror the same thing to go around the admin flow of GitHub. And then also many of them like regularly hash, manually things.

on IPFS to make sure that, okay, there is that too. And then they use their own website as the ceiling point for coordination. And then on your own website, you will basically say, these are my repos, this is, you know, the latest of that, right? So radical really, you know, if you have a DAO, it allows you to coordinate and to decide on like, you know, what is the canonical state of things through the coordination mechanism of your DAO. And then additionally, the second thing that we're very excited about is if you do not

have a DAO and you are on the peer-to-peer network and at some point you want the equivalent of a GitHub organization, what we do is we basically deploy a DAO for you on Ethereum and we demonstrate you why, you know, multisigs or, you know, even token-based schemes are actually much more powerful than, you know, the classic admin flow that GitHub gives you. So again, you know, we try to give tools to developers. We did not try to force a solution to everyone. You know, certain communities prefer to operate based on a benevolent dictator. And that's absolutely okay, and you can do this in Radical.

Other communities basically would want some coordination on the peer-to-peer layer. And then you have obviously the decentralized world, like the Web 3, where Daos right now are being really normalized and seeing a lot of users, we're also allowing them to control repostrustlessly. And maybe I can dive a little bit in more detail on how this looks like in the product, because we're actually working on this right now. I talked a little bit about having multiple maintainers on a project, and the bizarre model where you have multiple peers.

And in the application, in the upstream client, you can essentially switch between different source trees based on which peer you're interested in, right, in the network. So let's say you're looking at the radical project itself and you're like, oh, I'd like to see LA's source tree. I'd like to explore that. I was like, oh, I'd like to see clouded source tree. And you can switch between the different source trees,

source trees that you have available for a given project, right? Now, orgs, as we're developing them right now, are basically going to work the same way in the sense that you'll be able to switch your view of a project to the orgs view, to the orgs source tree, right? So it'll work just like another remote or another view of a project,

except this view will be decided based on rules that are encoded in Ethereum, as LA said, right? So, you know, if it's a multi-sacist, org, then a multi-sig transaction will be executed, which will decide what the official org view of this project should be. And then when you're browsing the project, you can switch to that view and look at what the org has essentially anchored on chain and notarized. So when you said, like, you know, look at L.A.'s source tree, you know, we mentioned earlier that, like, you know, repos or projects don't really have owners.

So what does that mean to look at someone's source tree? Would it just be, is it just more looking at a fork of the source tree that happens to have like L.A. as the sole writer. But it's not like his tree, right? And so then he could like take his fork and like add more maintainers to it. Like so I could convert my fork into something that will then, you know, eventually transition to being owned by. an Ethereum Dow, for example? Yeah, I think you got it right.

So every peer or user on the system has full ownership over their own source tree or fork, right? It doesn't mean they have ownership over the project, right, which as I said, is owned by the maintainers or the single maintainer. So each maintainer, each contributor, each person who wants to just sort of have their own copy of a certain project will have their own source tree, right? And then it's a question of trust, right? It's like if I trust Sunny, then I will follow Sunny's source tree, right, and be able to browse it, right? And maybe base my changes on or build Sonny's code into an executable, right, because I trust it.

So it's all about trust. And obviously, maintainers have a special status in the project. So you may want to, you know, base your changes on their tree. But for what I mentioned for orgs, it's the same thing. if you don't trust the org, then this is not giving you any new feature, right? It's not interesting to look at the org's view on a project. But if you do trust the org because, you know, this project was created by this org, for example, then that's something you would be really interested in having as your kind of default view on a project, for example.

I guess what I'm trying to understand is, like, how, what the difference here is between this and the GitHub model where it just turns into, like, you know, this project is still owned by this org. And like, what's different here then? If, you know, you're saying, okay, this Dow is this like maintainer that has the rights to change it. How is this any different? It's hard to wrap your head around. But basically, you know, on GitHub, a project is under a user or under an org.

And only under that user or that org, right? So if the tendermint codebase is under the tenement org, it cannot also be under Cloudhead or under Sunny, right? That would be essentially a different fork of that project with a separate issue list. So there is a sort of canonical place where it lives, right, under a certain hierarchy. And radical that isn't the case, right? So the tenement project doesn't live under the penerman org. You know, the tendermint org may have anchored a certain view of that project on chain and say, this is, this is tendermint, right?

But another org like Cosmos or Tenement 2 or whatever could do the same thing, right? And it just depends on which org you trust and you will want to follow that org and that org's view of the project. Does that make more sense? Yeah, I think so. One question I have then about like the development process is what are your thoughts on how how will this affect ux so you know i i have like friends in college still who are still learning computer science and for them you know learning git is always one of the most complicated things and

like this seems to make it like even more complicated like and like you know one of the things that having these like master repos helps is it like also provides a canonical ordering meanwhile if like everyone's like merging in patches from other people and like this like you know very secure scuttlebut like you know swarm like way won't this cause like all these like nightmares when it comes to things like rebasing because like you know i'm you know different people are merging in other people's code base changes in different orders yeah that's that's that's a really good question i mean you you know we we said um earlier that um oh like it's actually not that different from GitHub in a lot of ways.

But this point that you just brought up is what makes it actually quite different, right? Because in a peer-to-peer network, you have this sort of inherent subjectivity, right, where you don't have a full picture of the network. You see what you're connected to, what is available to you. You don't see everything like you would on GitHub, right?

So problems, like, you know, things like merge conflicts could happen more often than in a GitHub model, especially if you have multiple maintainers, right? Because this is a case where, you know, as a contributor, you want to contribute some changes. You pick one of the maintainers branch as the starting point to branch off of. You create some changes, but it so happens that a different maintainer had a more recent copy of the repository, right? And that's not something you knew because, you know, you're not connected to that maintainer.

And so there you would have a problem that would not have arise on GitHub, where there's only one place to look at for the most recent change, right? And there, there's a couple of things we're doing to improve that because it's kind of inherent to peer-to-peer networks because you have this asynchrony, right? One of the things we're doing, Ellie mentioned it a little bit earlier, is to have these seed nodes. and seed nodes are a little bit like pubs and SSB, or very much like pubs and SSB. They're essentially regular peers, but that are publicly available and always online, right? And this acts a little bit like a point of coordination where there would not normally be one, right? So if you think of a completely peer-to-peer network, it's kind of messy, right? and you can have these problems with availability emerging and everything.

But if you think of a peer-to-peer network that is supported by some nodes that are sort of points of coordination, the picture looks a little bit different because a maintainer where project can say, hey, we get all of our changes from the seed note. Maybe it's a community node. Maybe it's our own node. Maybe it's deployed by the maintainers. It doesn't really matter. But it's just a server where you can push data to.

and pull data from. And this really mitigates a lot of the problems with ordering, essentially. One last DeBX question I have is, for me, I actually do all my development on my laptop. I don't have, like, a desktop or anything like that. And one thing that GitHub provides is this, like, you know, always online storage and, like, available for anyone to pull from. how do you imagine like solving providing these sort of services to users are you guys going to work with like you know any of the you know there's a bunch of like blockchain storage project like you know

file coin and sire and whatnot or do you guys have some other solution in mind for this that's an interesting question i think um on the one side the experience is local first right so it means like all of the things you're working with, all of the artifacts and everything is on your machine. So on the one side, you can, you know, sort of work as you would usually, whether or not you're connected to the internet, right? What's going to happen is if you push a change that you want others to see, you know, it'll go through, but only once you reconnect to the internet or once you connect to certain nodes, will those changes be replicated, right? The seed nodes function as data availability nodes.

So this is one sort of way we can increase the replication factor of a certain project. And individual peers also work as replicators, right? So if you, again, just like the Scuttlebutt model, if

you follow me or my project and I push a change, you're going to replicate that change and you will be able to broadcast it to other peers and actually serve that content to other peers. even if I'm offline. And so by default, I start to, like, host the data of everyone who's, like, working on the same

project as me. You have to add the peers you want to follow and replicate for now. So it's an explicit action. Yeah, exactly. So what happens is that basically, you know, you have this social overlay, we call this, right? Like, where you basically communicate intent around. I'm interested in this repo, so I'm going to track that, right? And then I'm also, you know, like I actually like Alexi's work or I trust Alexi,

so I'm going to follow him. And then you have the social network that is basically emerging around that. And then by design, you replicate and you propagate in the network things around the repos and the users you're interested in. To add something to your question, to your previous question, we're also working on multi-device support, which is something that, you know, you mentioned that GitHub provides that for you today. So this is something that we understand that for a lot of users,

this aerial use case, and we're working on that. And then in terms of like, you know, permanence, which was, you know, your question, we're not really, you know, going beyond our peer-to-peer network yet, although, you know, we continue to just monitor the space. Like, you know, it's still quite early. Like, I don't know if you, you know, how much you have used most of the decentralized storage providers. but, you know, it's still quite early, but, you know, like both file coin, like SIA, like RWeave, Swarm, like they all progressing quite fast. We think that at some point they will be more usable.

So you can imagine, again, like, you know, an integration around, you know, certain, in certain seed nodes, for example, right? Like they take care of that. So that's something that we're not working on, but we're keeping an eye on to see how the space will converge. And then what we really think that's going to happen is more what happened with IPFS and pinning nodes. So we think that basically, like as radical seeing traction, then there will be certain providers that will basically say, hey, you know, pay me like, you know, a few dollars or a few crypto dollars. And basically, like, I'll take care of that for you.

So, but, you know, we're not on our side. We're much more focused on making the peer-to-peer and the end-user network, the end-user experience and the blockchain integrations work instead of actually like trying to offer. for some of these things yourself. Will this social overlay provide like some sort of hurdles as well, though? So like isn't one of the beauties of open source that I can like go to a GitHub repo that I don't know anything about the maintainers? I could be anonymous for all they know.

And I can still open an issue or, you know, provide a PR. But if there's this like manual peering that's required, doesn't this almost, you know, provide this like higher barrier to entry for people to collaborate? It does. It absolutely, it absolutely does. Like our solution to this is again, Cid nodes, meaning that,

you know, you have these always own nodes that appear. And what we think it's going to happen there is that they're going to have their own policies, you know, how they go about replicating data, right? And then, and then additionally,

you as a user, you can also, you know, eventually you will be able to configure how many degrees out you want data to probe. propagate, right? So you have this basically control switches, leverages that, you know, you can tune in to your own experience. And yeah, this is definitely, though, like the point absolutely stands, you know, it is a higher barrier to entry, but also we think that there are ways around

that. And Alex, I don't know if you want to add anything on that. Yeah, maybe one point on that is that the social overlay doesn't have to be the same for all kinds of artifacts on the network. So what I mean is maybe you're replicating, maybe the peers and the source trees you're replicating are chosen manually, right? But you can be open to receiving full requests from any user as long, of course, as you are aware of those changes, right? So since the radical network is essentially a gossip network, things of interest are broadcast and essentially flood the network in that way. and so peers get to know about a lot of things that they're not necessarily interested in like oh you know peer x created new branch y you know and it's like oh well i'm not tracking this project i'm not following this project so i don't care about that but i still know about it right

and so i think for things like like issues being open by you know some anonymous contributor or prs or things like that maintainers could could choose a policy where it's like hey if i receive a PR for one of my own projects from someone I don't know, I'm at least going to forward that to the client so that then, you know, the maintainer can look at it and either discard it if it's spam or actually, you know, look at it and merge it if it's not spam. But one thing to keep in mind is going the other direction with a more like, let's say, promiscuous policy where everything is sort of visible and replicated could lead to the opposite problem where, yeah, you have, you know, civil attacks and spam issues and abuse and things like that. And so it's kind of,

it's, you know, it's a, you know, it's aligned to tread, given that there's no sort of like moderators or moderation in the network, apart from individual user blocking or following. Okay, let's move to, I think, the last thing you guys mentioned in terms of, you know, what radical is providing. And I think you mentioned that sort of in the context of open source sustainability. Another phrase I've seen in, I think, some presentation of yours that, like, you know, I think it's a nice way of sort of looking at it is deaf buys, a developer finance. I guess sort of a play on the current defy hype or boom. So can you just like what, let's say radical succeeds, what does that change in terms of business models around open source,

yeah, the sustainability of open source development? That's a great question. So, yeah, like then, the defy thing is, more of a meme internally for now, but like, we'll see, you know, if this, you know, catch on. So, but yeah, like talking about sustainability. Today, like the, the solutions that developers have are, again, you know, mainly constrained on platforms, first of all. And then in terms of the solutions you have are very limited, right? So you have a small minority, like it's a small market around Bounties. So Bounties is one model that you see, you see in the industry.

the second model that now is getting more attention because of GitHub is the Patreon model, you know, Patreon slash GitHub sponsors slash Open Collective. And I'm simplifying things. There are some small differences between each and every one of those. But, you know, you can think of this more like donation type of model with a bit of in exchange of something, right? So that's the second thing. And then the third model that you have is really like the, okay, start the company, right? And then if you start the company, then what can you do?

Usually if you want to continue developing open source, then you do open core, most of the times, right? Which it is the model that, for example, you know, GitLab is using and a lot of different providers use. And the idea here is that you have an open source code base at the center. And then you develop, you know, paid features around that. And, you know, it could be paid features. It could be consulting. You know, this again, again, ranges, right? And then you also have the software as a service type of thing that,

you know, you subscribe to some kind of community addition. This is, you know, where the world is today. And what we really think is that, you know, blockchain fundamentally, you know, like bring an innovation around value, right? Like, and that's why we think that right now the current trend with Defi makes a lot of sense, simply because, you know, you just have this new playground to just design new, you know, financing models and new value flows while also, you know, doing this in a trustless way. So what we're looking to do is we're looking to introduce a number of these experiences.

We really think that, you know, this is not the right time to just say this is going to be the model. There are like, when we look at the developer space, we see a number of different ones. And I'll mention some that we think are interesting ones. So the first thing that we're working on is something that we call radical lists. And this is basically a social experience around giving. The way that it works is you as an open source supporter, you can set the budget and you can say, I'm interested in supporting open shores with 1,000 dye or another stable coin. And then what you can do is you can actually start curating a context-specific lists

for example, you know, like a on one prototype, you know, we have Vitalik curating a list of of ETH2.0 researchers or the best projects in ETH2.0, for example. And then now what you start doing is you basically start streaming your funds towards, you know, your lists. And additionally, anyone that basically lands on your profile can actually now see that these are the lists that you have curated and then also start supporting you. So it's a little bit like if you know awesome lists like awesome React or awesome Python, you can, like, you know, this these things that live on GitHub that developers curate a set of resources. Now you can imagine the same thing with money where basically you can have the best

projects within the cosmos ecosystem and then now anyone can actually see them, pass them around, support them, right? And you can basically support these projects. So this is one of the things that we're doing, which is more specific on the donation side of things, but we're making it much more social as an experience. The second thing that we're doing, which we think is interesting,

is we designing a feature that we call back and issue. So it's a bit like, you know, GitHub meets Kickstarter. So within your issue tracker, you will be able to actually like have issues associated with value, right? Like where you can say you as a maintainer, you can say like, hey, I'm only going to work in this issue if you, if my supporters basically pull together 1,000 I, right? And in addition to that, again, because we're using blockchains

and we think that blogchings are a better tool for aligning incentives. What we do is you can have schemes where, for example, 50% of the funds are released up front and 50% after a milestone has been reached. And the backer say, yay, you know, this has been met or nay, right? While today on existing platforms is all or nothing because of the, you know, of the way the technology they use works. So on Kickstarter, all the funds are released up front, right? So you can engineer, like, and you can engineer this,

in a very flexible way. So these are the two things that we're actually starting with. Now, additionally, like, there are a number of other things that are going on in the space that we really like and we're keeping an eye on. For example, this year you see a lot of attention around non-fundible tokens on Ethereum. So we have a number of ideas about non-fundable tokens where, you know, you as a supporter, for example, you know, you support an open source project in exchange, you get a non-fundable. token and within the experience now you have a special status like a bit of like you can think of it as a

special badge and then additionally you have certain functionality within the repo for example imagine you know only your supporters will be able to actually prioritize your issue tracker or potentially only your supporters might be able to access an issue tracker for example right so there are all of this you know like interesting experiences that that bringing value closer to the code collaboration experience now these are now like available. So we're looking at introducing some of them. And then maybe the final one that we're looking, we're not doing anything yet.

There's obviously this whole idea of social tokens. It's quite interesting because, you know, we've been like talking a bit about this internally. And it's so interesting that there's something very intuitively very like viral. You know, like we were joking about this in one session. And then, you know, immediately you could see the team start talking about like, oh, yeah, like I'll send you 10 clouds for Cloudhead, for example. there's something there that's very playful

and again if you combine this with some form of utility within the repo we think that there is something very interesting but nothing nothing to announce yet but maybe just to have a final thought on that what we really think that is going to happen is what started as a social network for developers like GitHub now is becoming also the place where eventually developers will be starting their own companies

their whole monetization will live in one of those companies. So we really want to actually take that to the extreme and see, like, observing what interesting is going on, what is interesting on the Ethereum world, on the DFI world, and then repurpose those, bring them back to the developer and basically allow developers to make a living. So you should expect a number of features, not one or two. Still more of a playground.

Let's see what sticks. Let's see what doesn't. Cool. I want to ask a last question of Alexis. So I remember even in the beginning when I met you, you were working as a hobby on some Bitcoin client in Rust. And then for the longest time, you guys were actually thinking of creating your own blockchain for a radical,

based on proof of work, which I think was a very contrary thing, right? Where basically everyone was building new blockchains on various types of proof of stake systems. So maybe as an Ethereum smart contracts. And now you guys are building on Ethereum as well. So I'm just curious to hear like, what is your thinking personally on, you know,

kind of the role in the importance of Bitcoin as well as role in the importance of Ethereum? Yeah, sure. I mean, that's like a very open-ended question, but I'm going to try to say smart things. So the first thing is that Ethereum offers us things that are, kind of hard to do without, right? We mentioned in the beginning like stable coins, right? Like developers want to receive donations or support and pay support using stable coins. And so that's something that at the moment only Ethereum really offers. The problem, however,

and the reason why we originally wanted to build a proof of work chain is for security. and because we were doing, you know, we were doing this OS rank thing that we just mentioned on chain, right? And you can't do that as a smart contract. It's too expensive. It needs to happen on layer one, essentially. So, you know, we were exploring, you know, proof of work, you know, due to the requirements of having a light client. one of the things I still really dislike with Ethereum is the centralization around things like Infura, right? Like, today it's impossible to run an Ethereum full node on your laptop or even on your desktop,

and there are no real light clients that are usable. You know, part of this is because the light client technology is, even though Ethereum is a proof of work chain at the moment still, you know, creating the, the right proofs for a system that allows freedom and programmability is really, really hard. And so one of the things I would like to see is actually some kind of integration of Bitcoin into Radical, maybe something around the Lightning Network,

to do instant payments for very, very cheap to developers, something that on Ethereum is looking more and more problematic due to the price of gas, right? So I think in the end, we're going to see sort of, you know, Ethereum shining for its connectivity and integration of all the different kind of smart contracts, you know, the liquidity around all these different tokens, the programmability, the ability to, you know, even maybe connect your donations to something like compound, to gain some yield.

things like that. You can do really interesting things. But for simple payments, for cheap payments, I'm still kind of looking at things like Lightning. And for people who also are paranoid or, you know, don't want to trust a third party to verify payments, again, something like Bitcoin and Lightning would work better, in my opinion. Maybe if I can add on that, yeah, I think everything Alexi said is right. The point that I want to communicate here is that we're not maximaist, like, you know, we're not maximalists.

Like, we really, like, you know, see value in different approaches, right? So we have a specific vision that we're going after and we realize through user sessions that this vision is relevant to a lot of people, not only to the Bitcoin or Ethereum community, but, you know, also to other big blockchain ecosystems. Like we have a lot of, you know,

friends that are excited about us on the cosmos ecosystem, for example, same story, you know, with parity. So all I'm trying to say here is that we, we have certain principles in mind, but beyond those principles, we really, like, you know, try to see what is needed and, like, you know, what is requested from our users and then basically, you know, work, work around that. Obviously, you know, one of the benefits that we see with Ethereum is that we feel that right now everyone will interoperate with Ethereum. So immediately Ethereum opens you up to this, you know, wider developer ecosystem. But as Alexi said, you know, there's also a trade-offs there.

So, yeah, long-store, short, we really, you know, keeping our eyes open, we're really working with our users. And then, you know, if what we're working on is relevant for more and this is, you know, something that our users want, we will actually work on that and bring that to more ecosystems. Cool. Well, thanks so much for joining us today, guys. It's been great to hear about the progress and to see kind of the upcoming, you know, Ethereum integration.

And, yeah, I'm really excited. And of course, to our listeners, I encourage everyone to like check it out, especially developers, right, play around with it. I think Sonny already played around with it upstream and he liked it. So, yeah, thanks. Yeah, thanks a lot, Brian, Sunny. Thank you for joining us on this week's episode. We release new episodes every week.

You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places

where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter.

And please leave us a review review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.