Alexis Sellier & Ele Diakomichalis: Radicle – The Decentralized Platform for Code Collaboration #378

Transcript

this is epicenter episode 378 with guests alexis celier and elephtarios dia coming [Music] callous [Music] hi i'm sebastien cutiero and you're listening to epicenter the podcast where we 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 if you like epicenter the best way to support us is to leave a review on apple podcasts if you're on a mac or ios device the easiest way to do that

is to go to dot rocks 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 podcast if you haven't subscribed yet you can do that on apple spotify or wherever you listen today our guests are alexis celier and elfterio's dia comicalis 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

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 uh 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 proposals there the code gets uh 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 come together around 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 the repo gets uh 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 so definitely check them out you can do that at epicenter dot rocks slash one inch that lets them know that we sent you and with that here's our conversation with alexis celier and eletherios diacomicalis we're here today with ellie and alexis from radical i've known him for a long time actually

i've alexis briefly worked for a tendermint in [Music] that must have been 2017 i think yeah briefly and then immediately started working on uh on radical although at the time it was called the west coin and uh yeah so i've sort of followed this project on for a long time it's also disclaimed that i 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 uh you know there's actually something out there that allows people to collaborate on code and you know we're gonna go a lot into what that means and what sort of

vision for radical a so thanks so much for joining us thank you for having us yeah thank you so yeah let's start there like what what is radical and what's the vision you guys are pursuing yeah a radical is a new kind of code collaboration network um 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 um it brings together um concepts like centralized organizations you know value flows things things that

we see a lot in the in the in the 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 why is it important to have uh code collaboration done in in a novel way in a decentralized way what's wrong with sort of the existing ways that's done we we see a number of problems with uh centralized code collaboration providers the biggest problem and a hot topic right now in the world is the problem of user and project censorship unfortunately most of the existing centralized providers basically you know have to limit the

usage to certain areas um like you know iran crimea like you know there are a number of places in the world so so when we're thinking about open source 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 the of our open source infrastructure so that's the first problem um additionally many of these centralized forges have not been designed with security in mind uh the you know we can zoom in on that quite a lot but the example that i always give there is that a few months ago there was this uh significant hack on twitter where some of the most um you know most um high-profile um accounts were compromised and then i

think the attacker was basically tweeting some kind of you know bitcoin like send me bitcoins type of link um so imagine you know similar attacks on your code collaboration infrastructure uh where someone potentially injects 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 uh simply because a lot of you know uh commits and github go on unsigned for example and then additionally you have like like when we're looking at decentralized forges there are a number of attacks that being pulled off on the on the social artifacts not only on the code side of things so secure our code collaboration and distribution of code bases 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 have engineered the number of things around those the most common being social collaboration and these obviously you know are locked into their own um to to their own platforms these are the the three things that we believe are really relevant for 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 a lot of we saw we saw the emergence of a lot of dows right these are 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 and what happens there is that actually like when they um they they all of them usually you know have some kind of code repository like where where they store the code uh most of these things are today on github and unfortunately there they actually they have to go through the classic admin flow of of some of the centralized providers where you know it doesn't matter if you are a dao 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 many ways this even worse given that each and every one of them now has has a lot of power over the community so what radical allows there is it allows uh decentralized organizations decentralized applications to control software reports trustlessly which we think is a very relevant point for them finally there's a an opportunity as well like today most developers still you know struggle with the problem of open sustainability this is you know has been a hot topic on the web for the last few years we personally think that blockchains enable new experiments around value flow and what we looking to do with radical is to actually to bring

them closer to the code collaboration experience and hopefully enable more humans to sustain their open source work and contribute to the comment 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 uh at one point and i think soundcloud uh you know i don't know not nearly 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 like what are your the lessons from from your time to soundcloud or how that experiment has played out that have kind of you know informed your approach to a radical yeah that that's that's a great question actually and what's so interesting is that many of us that joined a lot of the web 2. 2.0 platforms early on

you know the the vision and the 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 create creators to actually own more of their 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 like they were like you know like i don't know what was the official term but you know it was kind of gray like you know like gray type of content

specifically thing about dj mixes covers muscles 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 like and 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 um yeah that's that's one thing that 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 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 amms to save you money and time on swaps one inch finds the best possible trading paths across over 20 supported 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 going to epicenter dot rocks slash one inch that's one i n ch 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 git lab and sourceforge and especially when it comes to like you know git lab is open source and you can self-host it if you want so what does radical provide that like a self-hosted uh system would not so one of the problems with having um sort of relying on multiple competitors or multiple platforms as a as a way to reduce platform risk um is that a lot of these platforms uh at least the famous ones

are in the same jurisdictions right and so they actually don't necessarily behave differently um what i mean is if you have like a sort of like a political issue for example like we're seeing recently with uh you know geoblocking or uh 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 um 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 uh you know um hosting or like cloud providers etc because they they essentially end up all

doing the same things and censoring exactly the same users in the end yeah and and to add on that like if you really look at how these platforms are are are emerging and evolving um you know what started as a place for hosting key tripods now has become the place where my life's work you know is and lives right and not only that like now where where this whole space is going is that way this is where also when 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 our reliance on some of the systems you realize that in the future you might

be completely cancelled because one of these pro one of these platforms basically decided that they do not want to accept contributions from someone that visited iran but also your salary might be cancelled 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 with those in mind um so that's 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 um indeed there are a number of providers there's github gitlab guitar um like you know source hat there are many providers all of them you know speak kit 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 can 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 uh where you do not need to compromise your connectivity in order for you to actually you know be self-sovereign right and um yeah and that's what we think that we adding to the mix yeah maybe maybe to add to that there's no um global identity layer essentially if you go with

uh self-hosted instance your contributors are gonna have to create a new account every time so there's yeah there's really no social effects or network effects there yeah and maybe to add one more thing because it's 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 a number of attempts there you know none of them has actually materialized yet but um but even if they do the problem we see with federated systems is that you always rely on you know like okay pick your sysadmin great okay yes i can move away from that instance but you know your upset is as good as you know your you

know the practices of your sis 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-peer systems actually um are an answer to this problem and they are a much more preferred way to 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 uh an essay um by eric craven i'm not mistaken um where he talks about two kinds of development models right um one is a cathedral model where essentially you kind of have a sort of centralization around the repository and everyone kind of pushes and pulls um from that repo and some of the uh 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 um and git was built for that model right and they obviously have pros and cons um we if we look at github that's definitely definitely promoting the cathedral model because you have a single repository and you manage permissions right like an access control list um team members can push and pull there and

there's an admin and that's the cathedral model the i guess the the advantages obviously are that um for small projects um it's a lot easier to manage right because you have one place to look for to 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 um but of course you have you have issues with that um for example when it comes to scaling so to give an a different example the the linux kernel is managed in more of the bizarre model where you have a sort of hierarchy of maintainers um

that fetch and pull code from each other all the way up to linus who um you know has a sort of trusted set of maintainers he pulls code from and emerges 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 shoehorn the the sort of centralized repo approach of github would be very difficult but one thing to keep in mind is for uh in the case of a single repository single

maintainer sorry um so if you have a repository with only one maintainer there really is no big difference right because um 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 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 um or state um 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-band organization there so do you think that like 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 um and then the tools like github kind of nudge people to words using a cathed more cathedral-esque model do you think github was designed this way because the culture and users demanded the cathedral model or was it like pushing people towards that and then if you build this tooling for people to uh 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's developed um because even though um you know it it's not like the cathedral model was completely new right it was it was very much the way things were were working at the time and perhaps you could say github popularized it but um i think in terms of radical and and the bizarre model um it's definitely it's definitely a model that is today a lot less popular and that confuses some people um and

if we're going to be successful with the 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 uh for people who are new to code collaboration this is a lot easier right to explain and to work with um so it's gonna it's gonna take a little bit of of learning and a bit of adapting from a users but um i think we can influence things in that direction so i'm wondering if you can explore like a

let's just explain this a little bit more i i mean i i i understand the guitar mode 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 the software is developed how it's managed how is governed from following that different model yeah sure i i can i can give you an example so um 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 um for for any given repository there's only one user with right access to it okay so the first thing is it's closer to what we call the github open source model where you you have to fork a repository to contribute to it by ipr right um so currently so today already on github if you're working on an 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 you can have multiple maintainers who can merge changes right so one of the the core differences that you have to settle on what you want to be the canonical repository and for something like linux as i mentioned linus's kernel tree is the canonical one right and everyone knows this uh when you have a linux distribution like arch linux or red hat they will usually pull from his tree sourcetree to to release a new version of the operating system right and this is known and the same

thing applies for radicals so you have to figure this out within the team within the community for any given project that a certain user's sourcetree is the one that is considered canonical that is that is the main difference now we we are working for instance and we're going to talk about this a bit 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 linuses what what's actually the tangible difference then like it's is it just that there's more you know bran there's almost like sub masters where like you know uh instead of like getting merging everything to like the main master branch you know we have a bunch of like sub-branches that 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 you know traditional model let's use today so maybe one way to think about it that that could be helpful is that um in radical a project right which is the the kind of unit of collaboration in github it's called the repo we call it a project and radical a project is not um owned by a user so this is this is kind of so on on github if you look at um you know whatever the the bitcoin project it's under the bitcoin organization right so it's owned by the bitcoin organization right in radical um a project like bitcoin

would be um sort of self-sovereign in a sense or like it wouldn't have a an owner per se it wouldn't be under a certain user account necessarily right um what it would have is one or more maintainers right and you could say oh if there's one maintainer it's kind of like the owner right um which that could work as i said but now let's say there's 12 maintainers right um 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 it's a subtle difference but it means that projects essentially are

um sort of self-standing or like free-floating you could say and and to add on that for like maybe the less technical user so on github you land and immediately have this concept of main or master right which you know this is like the the state of things right now like and you know github basically makes that very easy for you in radical every project actually needs to go through its coordination phase of like agreeing on what's the canonical state of things for a newcomer you know you 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 sun is sunny branch is the canonical branch here right so so that's that's one difference the second the second difference with something like github is that in github you land um on the project and then you can you can see basically like you can see all branches right because i have a global database behind things um in 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 spanish branch around this project um and of course again you know there are ways where we can make this a lot simpler for you

uh by using something that we call seed nodes which are kind of like pinning nodes and ipfs or you know um but yeah these are two 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 peer-to-peer 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 uh you know which one's a canonical one also

the idea of like maintainers right and role maintainers uh came up i mean for me probably you know the place where this topic became was most kind of 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 was one thing uh and actually a lot of that controversy then ended up playing around you know what kind of things get merged into the 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 and the maintenance there so i'm curious if you yeah i 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 um yeah so so so bitcoin basically uh i think it was a couple of years ago it forked into bitcoin cash right and then um 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 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 um 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 um the kind of fork you would create would

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 um you would actually create a completely new project identity for that right it could have the same code the same history but its identity uh 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 the default radical tooling

of course so i think beyond that actually um there's not that much difference with what happened on github um what i mean is you in 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's either an intent to diverge or to converge towards the same goal i think the the only thing maybe worth worth saying that that is interesting with radical is the um maintenance of that project identity right so the uh the it's essentially a file um which has the product description the

list of maintainers and a bunch of other data the maintenance of that file is 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 um 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 super admin 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 a less well-defined um structure i would say compared to radical yeah and maybe maybe brian to add on that like and i'm actually glad i'm glad you asked because as of two weeks ago uh 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 corey was they 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 and 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 um they're mentioning the fact that 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 artifacts you know locked locked in in that platform uh so so playing the bitcoin core core uh 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 corribo this is a truly peer-to-peer network uh right so so you

have basically global available like you have better availability um around that that's one thing um and then um the 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 on open protocols not platforms including your social 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 uh win um and then you know basically censorship comes with that and then finally the the thing that alexi mentioned which in radical you have this delegation

scheme around around the repo so for certain critical operations you know you have to go through some kind of you know uh like vote you can think of it as a multi-sig you know you can think of it in many ways but that 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 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 change the content right so you know these 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 uh yeah so we're 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 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

um called git bug right it's um it's uh a tool i think built-in go and it essentially stores issues as get notes from what i remember which is a feature a native feature of git so it's very possible that we end up adopting that and build a front building a front end on top of it because our replication system um just replicates uh the get tree right it doesn't really care what objects are in there it will just replicate whatever is necessary and so we would we would essentially get that for free in terms of pull requests or our equivalent the kind of the

very basic way of doing that um 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 um and and for that we have our own system that we're working on that is um that is really really simple actually what comes after that is code review of course and that's that's a massive undertaking um you know github has been working on code review under on their code review flow for years and it new features come out every every month or every year or whatever so that's the more complicated one we don't have any plans on using an existing system yet although we

are taking some inspiration from gary uh namely uh in terms of how how the code is structured how the the code is proposed to be merged etc because github does have some limitations there in terms of the um 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 dolls so the you know these

organisms like kind of collectives on chain and you 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 uh on-chain uh 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 uh you make this kind of change but then the code the software was actually decoupled from that and you know the the entry governance can't enforce you know the change on on github so how 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 the on-chain governance that directly controls you know changes to the software repo and is that actually uh desirable yeah so that that's a great question maybe i think that's that's a good segue to basically say a few words about the radical architecture because i don't think that 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 you had dominic here maybe a few months or years ago so there's a peer-to-peer 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 uh you know it's available for everyone for free right and this is where you know you basically live most of the time um so that's that's layer one layer two is basically clients right and we 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

trying to build beautiful experiences around code collaboration realized especially you know 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 ethereum 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 you know there are a lot of developers that actually you know like do not like blockchains some of them do not like ethereum right like you have the maxi wars and all of that but what the blockchain gives us it fundamentally it gives us three things the one thing that it gives us is a 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 rippers around and all of that so 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 help a lot with discoverability and network effects the second thing is we actually leveraging um all the nice tooling that the theorem has around decentralized autonomous organizations or governance right so uh we mentioned before that you on the peer-to-peer layer you already

have a method to coordinate uh based on aquarium but that's actually quite limited if you want more if you want more sophisticated coordination schemes then you can actually use like all sorts of existing data frameworks on ethereum to coordinate around what's the canonical takeoff of your ipo 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 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 that comes 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 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 d5 protocol i have a dao and i want to coordinate on what's the canonical state of things here through my dao i do not want to actually trust uh you know the 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 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 has manually things on ipfs to make sure that okay there is that too and then they 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 so radical really you know if you have a dow it allows you to uh coordinate um and to decide on like you know what is the canonical state of things through the coordination mechanisms 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 dial for you on ethereum and we're demonstrating 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 the 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 you know the web 3 that where does right now are being really normalized and seeing a lot of a lot of usage we also allowing them to control reports trustlessly and and maybe i can 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 you know having multiple maintainers on a project and you know the bizarre model where you have multiple peers and in in the application in the upstream client you can essentially you know switch between different source trees based on which peer you're interested in right in the network so let's say um you're looking at the radical project itself

and you're like oh i'd like to see you know la's la source tree i'd like to explore that i was like oh i'd like to see clouded sourcetree and you can you can switch between the different 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 org source tree right so it'll work just like another remote or another view of a project um except this view will be decided based on rules that are encoded in ethereum as ellie said right so you know if if it's a if it's a multi-sig org then a a multi-sig transaction

will be executed which will decide what the 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 la'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 like 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 la 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 i think you 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 over the project right which i as i said is owned by the maintainers or the with a single maintainer so each maintainer each contributor each you know 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 sourcetree right and be able to browse it right and maybe base my changes on or or build um sunny's code into an executable right because i because i trust it so um 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 for what i mentioned for orgs it's the same thing if you if you don't trust the org then then this is not giving you any new feature right it's not interesting to look at the orgs view on a project but if you do trust the org because um you know it's this project was created by this org for example

then that's something you'd be really interested in having as your 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 were saying okay this dao is this like maintainer that has the right to change it how is this any different it's hard to to wrap your head around but basically you know on github a project is under a user or under an org um and only under that user or that org right so

if you know the tendermint code base is under the tenement org it cannot also be under cloudhead or under sunny right that would be a a essentially a different fork of that project with a separate issue list and right um 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 the tenerman's project doesn't live under the tenerman org you know the tenerman org may have anchored um a certain view of that project on chain and say this is this is tendermint right but another org like cosmos or tendermint ii 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 or its 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 what are your thoughts on how the 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 scuttlebutt 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 uh code base changes in different orders yeah that's that's a really good question i mean you you you know we we said um earlier that um you know oh like it it's actually not that different from github in a lot of ways but this this point that you just brought up is what makes it actually quite different right because um 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 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 um especially uh if you have multiple maintainers right because this is a case where um you know you you as a as a contributor you want to contribute some changes you pick uh one of the maintainers branch as the the starting point to branch off of you you create some changes but it so happens that a different maintainer had a more recent copy of the repository right and 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 a rise on github where there's only one place to look at for the most recent change right and there there's there's a couple of things we're doing to improve that because it's it's kind of inherent to peer-to-peer networks um because you you have this uh asynchrony right one of the things we're doing um ellie mentioned it a little bit earlier is to have these seed nodes and seed nodes are a little bit like like pubs in ssb or very much like pubs in ssb they're essentially regular peers but that are publicly available and always online right and this this acts a little bit like a

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 these problems with availability merging and everything but if you think of a peer-to-peer network that is um supported by some nodes that are sort of points of coordination the picture looks a little bit different because a um a maintainer or project can say hey we get all of our changes from this seed note maybe it's a community node maybe it's our own node maybe it's you know deployed by the maintainers it doesn't really matter but it's it's just a server where you can push data to and pull data from and this really uh mitigates a lot of

the the problems with uh ordering essentially one last debex 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 uh 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 projects like you know filecoin and saya 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 the experience is local first right so it means like all of the things you're working with all 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 uh replicators right so um if you um again just like the the scuttlebutt model if you follow me um 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 uh the peers you want to follow and replicate for now so it's an explicit action yeah exactly so so what what happened 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 gonna track that right and then i'm also you know like i actually like alex's work or i trust alexi so i'm gonna follow him um and then you have the social network that is basically emerging around that and then 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 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 you know use case and we're working on that and then in terms of like you know permanence which was you know your 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 this you know it's still quite early like i don't know if you you know how much you you have used most of the decentralized storage providers but you know it's still quite early but you know like both file going like saya like are weave 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 um you know certain insert and 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 to see how the space will uh will converge um and then what we really think it's gonna happen is more what happened with ipfs and pinning nodes so you we we think that basically like as radical is seeing traction then there will be certain providers that will basically say hey you know pay me like you know a few a few uh dollars or a few crypto dollars and basically like i'll i'll take care of that for you um so but you know we're not on our side we much more focused on making the peer-to-peer and the end user the peer peer network the end user experience and the blocks integrations work instead of actually like trying to

offer 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 um 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 uh it absolutely it absolutely does like our solution to this is again signals meaning that you know you have these

always own nodes that appear and and what we think that'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 propagate right so you have this basically controlled switches leverages that you you know you can tune in to your own experience and um yeah this is this is definitely though like the point absolutely stands you know it is about it is a higher barrier to entry but also we think that there are ways around that and alexa don't know if you want to add anything on that yeah maybe one one point on that is that um the

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 that maybe that the peers and the source trees you're replicating are chosen manually right but you can be open to receiving pull 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 pure 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 um 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 the maintainer can can look at it and either discard it if it's spam or um 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 uh let's say promiscuous policy um

where everything is sort of visible and and uh and replicated could lead to the opposite problem where um yeah you have you know civil attacks and spam issues and uh abuse and things like that and so it's kind of um it's it's a you know it's it's a line to to 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 let's move to i think the last uh the last thing you guys mentioned in terms of you know what what radical is providing and i think you mentioned that

sort of in the 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 a nice way of sort of uh looking at it is death by so developer finance uh you know i guess sort of a play on the the current defy hype or boom so can you just like what let's say radical succeeds what does that change in terms of you know business models around open source uh yeah the sustainability of you know open source development that's a great question so yeah like

then the the you know the the fi thing is more of a meme internally for now but like we'll see you know if this you know cuts john so but yeah like talking about sustainability today like the the solutions that developers have are uh 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 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 uh slash

open collective and i'm simplifying things there are some small differences between each and every one of those but um you know you can think of this more like a 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 is um 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 you subscribe to some kind of community edition this is you know where the world is today um and um what do we really think is that you know blockchains fundamentally you know like bring an innovation around value right like and that's why we think that right now the current thread with d5 makes a lot of sense simply because you know you just have this new um playground to just design new you know financing models and and and new value flows uh while also you know um doing this in a trustless way so what

we're looking to do is we're looking to um introduce a number of these experiences we really think that you know this is not the right time to just say this is gonna be the model they are like when we look at the the the developer space we see a number of different ones and i'll mention some um that we think are interesting ones uh so the first thing that we're working on is is a something that we call radical lists and and and this is basically a social experience around giving the way that it works um is you as a as an open source supporter you can set the budget and you can say i'm interested in supporting open source with 1 000 die or you know another stable coin and then um what you can do

is you can actually start curating um a contact context specific lists for example you know like a on one prototype you know we have vitalik curating a list of east 2.0 researchers or the best projects you need to point out for example and then now what you start doing is you basically start streaming uh 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 um awesome lists like awesome react or awesome python you can like you know 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 you know the best projects within the cosmos ecosystem and then now anyone can actually see them pass them around support them right and 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 with making it much more social as an experience um the second thing that we're doing which is which we think is interesting is we're designing a feature that we call back and issue so it's a bit like you know github meets kickstarter so uh within within your uh esc tracker uh 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 that like hey i'm only going

to work on this issue if you um if you if my supporters basically pull together 1000 i right and in addition to that again because we're using blockchains and we think that blockchains are a better tool for aligning incentives what we do is you can 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 backers 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 and kickstarter all the funds are released up front right so you can engineer like and you can engineer this in in a very flexible way um so that's these are the two things

that we're actually starting with now additionally like there are a number of other things that's 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 our non-fungible tokens on ethereum right 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 an unfundable token and within the experience now you have a special status like a bit of like you can think of it as a special budge 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 isu 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 so we're looking at uh 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 it's quite interesting because you know we've been we've been like talking a bit about this internally and it's so interesting that there's something very um 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 started talking about like oh yeah like i'll send you 10 clouds for cloudhead for example right like

there's something there that's very playful um 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 um what we really think that is going to happen is what started as a social network for developers like github now is becoming also you know the place where eventually developers will be starting their own companies their whole monetization you know we live in in one of those companies so we really you know want to actually you know take that to the extreme and see like observing what what interesting is going on uh what is interesting on the

on the ethereum world on the defy 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 just wanted to ask a last a last question of alexis so i i remember even in beginning when i met you you were working on sort of 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 uh for a radical based on proof of work which which i think was very contrarian thing right where basically

everyone was building new blockchains on on various types of proof-of-stake systems or maybe in term maybe as ethereum smart contracts and now you guys are building uh on ethereum as well so i'm just curious to hear like what is your thinking personally on you know kind of the role and importance of bitcoin as well as role importance of ethereum yeah sure i mean that's that's like a very open-ended question but i'm gonna try to to say smart things um so the the first thing is that um ethereum offers us things that are kind of um hard to do without right um we mentioned in the beginning like uh 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 and the reason why we originally wanted to build a proof of work chain is for security and because we were doing um you know we were doing this os rank thing that we just mentioned on chain right and you can't do that on uh as a smart contract it's too expensive it needs to happen at the layer on layer one essentially so you know we were we were exploring um you know proof of work you know due to the requirements of uh um having a light client

um one of the things i still really dislike with ethereum is the centralization around things like infuria right like it's it's today it's impossible to run a an ethereum full node on your laptop or even on your desktop and there are no real like clients that are usable uh you know part of this is because uh the like client technology is uh even even though ethereum is a proof of work chain at the moment still you know creating the the right proofs um for a system that allows complete 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 you know 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 the price of gas right um so i think in in the end we're gonna see sort of um you know ethereum uh shining for its connectivity and integration of all the different kind of smart contracts you know the the the liquidity around all these different tokens the programmability um the ability to you know even maybe connect your your your donations to something like uh like compound to gain some yield and

things like that you can do really interesting things but for simple payments uh for cheap payments um i'm still kind of looking at things like lightning and for people who are also are paranoid or um you know don't want to trust a third party to to verify payments um again something like bitcoin and lightning would work better in my opinion maybe if i if i can add on that uh yeah i think everything lexi said is is right the point that i want to communicate here is that you know we're not do we not maxis 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 other big plugs and 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 um 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 from from our users um 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 developer ecosystem but as alexis said you know there's also trade-offs there so yeah long story short we we really you know keeping our eyes open really working with our users and then you know if 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 and bring that to more ecosystems cool well thanks so much for uh 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 the developers right play around with it i think sunny already played around with upstream and uh he liked it so yeah thanks yeah thanks a lot brian sonny 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 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 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 you