Episode 378

Radicle – The Decentralized Platform for Code Collaboration

  • Play

  • Play

  • Play

  • Play

  • Play

  • Play

  • Play

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 discussed in the 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 tool



Brian: We’re here today with Ele and Alexis from Radicle. I’ve known him for a long time. Actually, I’ve Alexis briefly worked for Tendermint in that must’ve been 2017, I think. Then immediately started working on Radicle, though at the time it was called the OS Coin. Yeah, I followed this project for a long time. Should also disclaim that I invested in the project back then. It’s very exciting to see like how far it’s come and now there’s actually something out there that allows people to collaborate on code and we’re going to go a lot into what that means and what the vision is for Radicle. Thanks so much for joining us.

Alexis & Eleftherios: Thank you for having us. Yeah. Thank you.

Brian: Yeah, what is Radicle and what vision you guys are pursuing.

Eleftherios: Yeah. Radicle is a new 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 value flows, things that we see a lot in the blockchain ecosystem, it brings some of those closer to the code collaboration experience.

Brian: Just to wrap our heads around a little bit, why is it important to have a code collaboration done in a novel way? And what’s wrong with the existing waste that’s done?

Eleftherios: We see a number of problems with 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 have to limit usage in certain areas like Iran, Crimea, there are a number of places in the world.

When we thinking about open source as being truly open, you immediately start to realize that there are all of these different arbitrary rules that come into play that limit the openness of our open source infrastructure. That’s the first problem.

Additionally, many of the centralized forces have not been designed with security in mind. We can zoom in on that quite a lot. The example that I always give is that a few months ago there was this significant hack on Twitter where some of the most Mo most high profile accounts were compromised.

I think the attacker was basically tweeting some kinds of send me Bitcoin type of link. Imagine similar attacks on your code collaboration infrastructure, where someone potentially injects something in a very significant code base. As the maintainer of the project, potentially, you wouldn’t even be able to notice simply because a lot of commits to GitHub go un-signed for example.

Then additionally, you have like when we’re looking at decentralized forks, is there are a number of attacks that are being pulled off on the social arts front, not only on the code side of things, also secure our code collaboration and distribution of code base. We think that it’s a fundamental problem with centralized infrastructure. Censorship, one. Security, second. Then additionally, you have a number of other problems, obviously vendor login.

Most of these platforms today speak git. They actually operate based on an open protocol, but they haven’t near the number of things around those, the most common being social collaboration, and this obviously is locked into their own to their own platforms. These are the three things that we believe are really relevant for everyone.

Then additionally, you have a number of problems that actually are specific to the decentralized world. The decentralized world, especially last year, a lot of what we saw, we showed the emergence of a lot of DAOs. These are groups of people that actually go through the process of coordination and the pain of coordination many times to actually align incentives. What happens there, all of them usually have some code repository, where did they store their code?

Most of these things are today on GitHub. There, unfortunately, they have to go through the classic admin flow of some of the centralized providers where 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 the steps of the code base.

You can have multiple ones, but actually in many ways, it’s even worse given that each and every one of them now has a lot of power over the community. What Radicle allows there is allows our decentralized organizations, decentralized applications to control software, post trustless, which we think is a very relevant point for them.

Finally, there’s an opportunity as well, today, most developers still struggle with the problem of open source sustainability. This has been a hot topic on the web for the last few years. We personally think that blockchains enable new experiments around value flow. What we are looking to do with Radicle lists 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 commons.

Yeah, a number of topics, but central, security, vendor lock-in, decentralized ownership, and then sustainability. These are the five problems that we see with centralized collaboration platforms.

Brian: Cool. You guys were both at SoundCloud at one point, and I think SoundCloud I don’t know nearly as much as you about this, but I think SoundCloud also had this vision around collaborating and creating music, distributing music, and like a different approach that was maybe a bit more like open and decentralized. In the end, It seems like it didn’t really succeed there. You had maybe more closed platforms like Spotify, Apple music, et cetera, that ended up winning. I don’t know if that assessment is right. But I’m curious, what are the lessons from your time at SoundCloud or how that experience has played out that has kind of informed your approach to Radicle?

Eleftherios: Yeah, that’s a great question, actually. What’s so interesting is that many of us that joined a lot of the Web Two 2.0 platforms early on the vision and the excitement was coming again from disintermediation. It’s the same story. In the music industry, back then, we were hoping that we would be able to actually develop platforms, experiences, and products that will enable creators to actually own more of the creative process. As you said, I think with SoundCloud, we really succeeded culturally. I believe that SoundCloud had a really significant impact in the music industry.

Really normalized things that the music industry didn’t want to look at. I don’t remember what was the official term, but it was like gray type of content, specifically things about DJ mixes, covers, mashups. All of those things that now are normalized. But obviously we think that SoundCloud failed to truly realize this disintermediation. Creators today are still customers of SoundCloud. They’re not owners.

This is where crypto and the Web Three is very interesting for us simply because it has this promise of community owned and operated networks where you know that no platform can actually get extracted against you. You can be the platform. That’s one thing that we really keep close to our hearts and it’s the North star for some of the work that we’re doing with Radicle, how can we actually enable developers to have that power over the tools they use every day?

Sunny: To dive in a bit now into like some of the features and visions that you talked about. 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, rather than just promoting more competition at the service provider level? GitHub is still the dominant platform, but there’s also other competition from products like GitLab and SourceForge, and especially when GitLab is open source and you can self host if you want. What does Radicle provide that a self hosted system would not?

Alexis: One of the problems with having relying on multiple competitors or multiple platforms as a way to reduce platform risk, is that a lot of these platforms, at least the famous ones are in the same jurisdictions. They actually don’t necessarily behave differently. What I mean is if you have a political issue, for example, we’re seeing recently with geo-blocking or embargoes and things like that. It’s very likely that all of the platforms will actually behave the same way.

They will take the same steps, block the same users. There isn’t really any benefit in jumping from one platform to the other, because you essentially end up in the same exact situation. It’s the same thing with hosting or like cloud providers, et cetera, because they essentially ended up all doing the same things and censoring exactly the same users in the end.

Eleftherios: Yeah. To add on that, if you really look at how these platforms are emerging and evolving what started as a place for hosting git repos now has become the place where my life’s work is and lives. Now where this whole space is going, is that this is where also when I make my income, like you have sponsors. You basically take some of these problems that start as, Oh, my contribution is blocked or my account is blocked.

Looking at the trend and our reliance on some of the systems, you realize that in the future, you might be completely canceled because one of these, 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 canceled, you know? You have all of these systemic risks that we don’t. We really do not think that the web 2.0 was designed with those in mind. That’s one thing.

Then 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, Gitea, there are many providers, all of them speak git. Then many of them are for self hosted instances, but what’s really going on is that you are almost like confronted with this decision that either I go for convenience and connectivity.

Either I’m on the community edition of GitHub and anyone can find me or I isolate. I have control by running a self hosted instance that basically no other actor can access. You don’t have the network effects, discoverability and all of that. Radicle 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. Yeah. That’s what we think that we are adding to the mix.

Alexis: Yeah. Maybe to add to that, there’s no global identity layer. Essentially, if you go with a self hosted instance, your contributors are going to have to create a new account every time. There’s really no social effects or network effects there.

Eleftherios: Yeah. Maybe to add one more thing, because it’s an interesting one and there are attempts for a federated Git, basically, you would say a federated git network. If you search for that, you will find a number of attempts there 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, okay, pick your SYS Admin. Great.

Okay. Yes. I can move away from that instance. But you know, your OPSEC is as good as your the practices of your SYS admin and also, based on evidence, in the past evidence, we see that again, you have the same centralization tendencies where one instance will become the canonical one and then you have, again, the same issues with power and trust. We think that peer to peer systems are an answer to this problem. They are a much more preferred way to approach that. That’s why Radicle is engineered as one.

Sunny: One of the things that I think is also very different is not only are you guys focused on tooling, but also in this larger process of open source development. You guys are very throughout your documentation, you always bring up this cathedral versus a bazaar model. Could you maybe talk a little bit about that and then how that shapes what you guys are building?

Alexis: Yeah. The Cathedral and the Bazaar was an essay by Eric Raymond. I’m not mistaken where he talks about two kinds of development models. One is the cathedral model where essentially you have a centralization around the repository and everyone pushes and pulls from that repo. Some of the now less used version control systems like SVN were built around that model.

Then the bazaar model is very different. It’s much more peer to peer and you essentially don’t really have a canonical master repository. Instead you have many, and they operate in a more peer-to-peer way. Git was built for that model. 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. Like an access control list, team members can push and pull there. There’s an admin and that’s the cathedral model.

The advantages obviously are that for small projects, it’s a lot easier to manage. Because you have one place to look for, to pull from, to download from and to manage. It’s very easy to see what the latest commit is and such a repository. But of course you have issues with that, for example, when it comes to scaling.

To give a different example, the Linux kernel is managed in more of the bazaar model, where you have a hierarchy of maintainers that fetch and pull code from each other all the way up to Linus who has a trusted set of maintainers. He pulls code from and merges. This model scales a lot better for that reason, but of course it can be a little bit daunting to approach.

In terms of Radicle. Since we were designing a peer to peer system, we found that the Bazaar model was a much more natural fit essentially. Trying to shoehorn the 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. If you have a repository with only one maintainer, there really is no big difference. Because you do have a canonical place to pull code from, and the maintainers, the only one who pushes to that repository.

In that case, it’s the same. It gets more complicated when you have multiple maintainers and bigger projects there you’re forced to a point a lead and to say, okay, this is this maintainable hold the latest or the canonical changes or state, whereas these other maintainers are going to work with staging branches or whatever it is. You have to have some added organization there.

Sunny: Do you think that like the tooling is a product of culture or is it more an input into culture? What I mean by that is like you said, Git, can be used in this very bazaar or cathedral model. Then the tools that GitHub nudge people towards using a more cathedralesque 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 the tooling for people to develop in a more bazaar 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?

Alexis: There’s definitely a little bit of both. I think it did have a huge influence on the way software is developed. Because even though it’s not like the Catedral model was completely new. It was very much the way things were working at the time. Perhaps you could say GitHub popularized it. But I think in terms of Radicle and the bazaar model, it’s definitely a model that is today a lot less popular and that confuses some people.

If we’re going to be successful with a project we’re going to have to make that model more accessible. 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. For people who are new to code collaboration, this is a lot easier to explain and to work with. It’s gonna take a little bit of learning and a bit of adapting from the users, but I think we can influence things in that direction.

Brian: I’m wondering if you can explain this a little bit more. I mean, I understand that cathedral model on a high level, but, let’s say now you had a project that was developing in this more bazaar way, what does this actually look like? And what are some of the tangible differences in terms of maybe how the software is developed, how it’s managed, how it’s governed from following that different model.

Alexis: Yeah, sure. I can give you an example. Maybe one way to think about it is that on GitHubs, you have a project that is not necessarily attached to a single user. It may be under a user account, but multiple users have write access to that project. Radicle for any given repository, only one user would write access to it.

The first thing is it’s closer to what we call the GitHub open source model, where you have to fork the repository to contribute to it by PR. Currently, on GitHub, if you’re working on open source or contributing to an open source project, you don’t ask for write access. 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.

Radicle is a lot closer to that, but you can have multiple maintainers who can merge changes. 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, everyone knows this. When you have a Linux distribution like Arch Linux or Red Hat, they will usually pull from his tree to release a new version of the operating system.

This is known and the same thing applies for Radicle. You have to figure this out within the team, within the community for any given project that certain users’ 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 a bit later, I think, but about how Ethereum, for instance, could help with figuring out a canonical tree.

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 user’s tree is the canonical one. This is where you push and pull from. But yeah, in the pure peer to peer model, this is something that needs to be decided per project, essentially.

Sunny: I’m still having some trouble understanding. Then what’s the difference if there’s still one canonical version of the repo, which is whether it Linus’, what’s actually the tangible difference than, is it just that there’s more, there’s almost like sub masters where like instead of like getting merging everything to like the main master branch we have a bunch of like sub branches that were merging to those. Then eventually those, it’s more of a tree rather than like a single hub and spoke system. But, I’m not fully understanding what makes this, that much less hierarchical than traditional models used today.

Alexis: Maybe one way to think about it, that could be helpful is that in Radicle a project, the unit of collaboration in GitHub, we call it a project. In Radicle a project is not owned by a user. This is kind of, so on GitHub, if you look at whatever the Bitcoin project it’s under the Bitcoin organization. It’s owned by the Bitcoin organization. In Radicle project. Bitcoin would be self sovereign in a sense where 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. You could say, Oh, if there’s one maintainer, it’s like the owner. Which could work, as I said, but now let’s say there’s 12 maintainers. You have this project with a bunch of maintainers and there is no immediate indication of who owns this or where you can find it basically. It’s a subtle difference, but it means that projects essentially are self-standing or free floating could say.

Eleftherios: To add on that for the less technical user. On GitHub, you land and immediately have this concept of main or master. Which this is like the state of things right now, and GitHub basically makes that very easy. In Radicle, every project needs to go through this coordination phase of agreeing on what the canonical state of things for a newcomer you land on a project. You’re, okay, how do I know? What is the latest here.

There’s this coordination step that we try to make very simple for you. Imagine like a little label that says, Sunny’s branch is the canonical branch. That’s one difference. The second difference with something like GitHub is not going to GitHub, you land on the project, you can see all branches, because they have a global database behind things. In Radicle, you need to be more explicit about that. You need to more explicitly request on the peer to peer network. I’m interested in Bryan’s branch and Sunny’s branch around this project.

Of course, again there are ways where we can make this a lot simpler for you by using something that we call seed nodes, which are like pinning nodes on IPFS. These are two immediate differences that no master main, you need to coordinate on a per project basis. Then the second thing is that not access to all the data, this is a peer to peer network. You need to be explicit about which views within the project you actually want to replicate.

Brian: We’ve touched on it in a few ways now. You mentioned the beginning, okay. This year of allowing decentralized organizations, controlling software repos we now talked about different branches having which ones are canonical. Also the idea of who are the maintainers? The place where this topic came most to my attention was like years ago in Bitcoin. There was a lot of controversy about where the project should go. I think for example, the block size was one thing.

A lot of that controversy then ended up playing around what things get merged into the core repo? Who’s the maintainer of that? Then you had certain people being removed there, you ended up people making forks and but then you, of course you had the shelling point around your this one GitHub repo that people know as the Bitcoin GitHub repo.

If I just fork it, then it’s very hard to get people to go around that. You ended up having this almost accidental point of control over Bitcoin that ended up being with decentralized software and to maintain yourself. I’m curious if you yeah. Can I expand a little bit and talk a little bit about that and talk a little bit about how, in a Radicle based development world, this would look like?

Alexis: Yeah. Interesting. Yeah. Bitcoin basically, it was a couple of years ago forked into Bitcoin cash. Then Bitcoin SV a little bit later was a fork of Bitcoin cash. Now there’s 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 exists in software collaboration.

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. 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 into upstream.

In the Radicle world, we have something called the project ID for each project. These are, it’s essentially a hash of some metadata around the project. If you are intending to make changes to a project that you intend to be merged back, the fork you create would preserve the original project ID. You would essentially create a just a new branch on the same project published that.

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. 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.

It would have a different identity. Then these projects could no longer be merged back into one, essentially through the default Radicle tooling. Of course. I think beyond that, actually, there’s not that much difference with what happened on GitHub. What I mean is you, in both cases you have a bunch of maintainers that are in control of a project or repository.

In both cases, there’s either an intent to diverge or to converge towards the same goal. I think the only thing maybe worth saying that is interesting and Radicle is the maintenance of that project identity. The it’s essentially a file, which has the product description, that list of maintainers and a bunch of other data, the maintenance of that file is, goes through a quorum. 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.

This is something that perhaps would be helpful in this situation because you would have a clear governance model around that, compared to GitHub where you have super-admin that can remove other admins but can never be removed. 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. There you have a less well-defined structure, I would say, compared to Radicle.

Eleftherios: To add on that, I’m glad you asked because as of two weeks ago, one of the core maintainers of Bitcoin core basically started experimenting with Radicle. If you go on Radicle, you will be able to find Bitcoin Core, and he also wrote a blog post about how they are planning on decentralizing their process.

They mentioned a number of steps there and they also talk about Radicle and specifically they talk a lot more about this whole idea of vendor lock-in like specifically mentioning the fact that, Hey, we can, we can jump to the next platform but now basically we have all of our social artifacts locked in that platform.

Playing the Bitcoin core scenario, what would Bitcoin core win from being on Radicle? Number one they would rely on a peer to peer network. They won’t have to rely on any company for the distribution of the Bitcoin core repo, because this is a truly peer to peer network. You have basically global available, you have better availability around that. That’s one thing.

Then there, the second thing you have is that in Radicle, basically the social artifacts live within the git object. That’s what we mean on the website, talking about built on open protocols, not platforms, including your social artifacts, no corporation owns them. They can actually move, they can move them away without actually having to worry about that. That’s the second thing that they immediately win. Then basically censorship comes with that.

Finally, the thing that Alexi mentioned, which in Radicle, you have this delegation scheme around repo. For certain critical operations you have to go through some kind of vote. You can think of it as multisig. 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 I might go, Oh, what’s happened, for example, on, I think the Reddit community, there’s this famous story on Bitcoin. They were on the fork, they decided to keep the name, the shelling point, but actually change the content. These type of things, you can deal much better with them and Radicle.

Sunny: When it comes to the social stuff, there’ve been past systems which have incorporated social features into the git repo itself, rather than this 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 existing solutions.

Alexis: Yeah. We’re in the process of developing these right now. The two main ones obviously are pull requests or merge requests and the other is issues. 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.

It’s a tool, I think, built in git and it essentially stores issues as git notes from what I remember, which was a feature, a native feature of get. It’s very possible that we ended up adopting that and building a front end on top of it because our replication system just replicates the Git tree. It doesn’t really care what objects are in there. I will just replicate whatever is necessary. 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. It’s really just a branch plus the intent of merging. For that, we have our own system that we’re working on that is really simple.

What comes after that is code review, of course. That’s a massive undertaking. GitHub has been working on their Code Review flow for years, and are releasing features for that workflow regularly. That’s more complicated. One. We don’t have any plans on using an existing system.

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 of the history of a forced push, for example. 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.

Brian: I did want to actually ask just a follow-up to the previous thing. Today, you have a lot of new blockchains that have on chain governance or people create like DAOs, collectives on chain. As you guys pointed out before often there’s some code repo genuinely on GitHub. That manages this code, that’s run by this on chain project.

Then of course you do have to challenge right. Then let’s say… to give cosmos as an example, some governance proposal to make some change, but then the software repo is actually decoupled from that. The on chain governance can’t enforce the change on GitHub. How is that going to work with Radicle? To what extent can you couple those things, so that it’s really the on chain governance that directly controls your changes to the software repo, and is that actually desirable?

Eleftherios: Yeah. That’s a great question. I think that’s a good segue to basically say a few words about the Radicle architecture. Radicle has three components. Conceptually there is the peer to peer network, which is a peer to peer network organized around git. The main innovation we bring to the mix is introducing the social overlay around, git repos that looks a lot like secure scuttlebutt. I think you had Dominic here maybe a few months or years ago.

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 a blockchain, you don’t need to hold any tokens or anything like that. You know, it’s available for everyone for free. Then this is where you basically live most of the time. That’s layer one.

Layer two is basically clients. We, what we’ve done already is we developed a client that we call upstream, that actors, the main user interface, you download this locally, and we all let the support Mac and Linux. We actually spend quite a lot of time on trying to build beautiful experiences around code collaboration, realize, especially for new developers, this is very important. GitHub has been very impactful in that second layer.

Then the third layer is what we call our Ethereum integration, the Ethereum layer. This is an opt-in layer. You do not need to use this if you don’t want to. There are a lot of developers that actually do not like blockchains. Some of them did not like Ethereum.

Like you have the backseat Wars and all of that, but what the blocks in gives us, it fundamentally, it gives us three things. The one thing that it gives us is canonicity. You can think of the blockchain as a global database. Canonicity is very important for things like global names, for example, and discoverability.

GitHub has been so significant, because of how easy it is to pass repos around. We are developing that around blockchain, and actually developing a registrar that is compatible with the Ethereum name, service ENS. That’s one thing that we believe that will actually help a lot with discoverability network effects. The second thing is we are actually leveraging all the nice tooling that Ethereum has around decentralized autonomous organizations or governance.

We mentioned before that on the peer-to-peer layer, you already have a method to coordinate based on the quarter, but that’s actually quite limited. If you want more sophisticated coordination schemes, then you can actually use alters of existing DAO frameworks on the Ethereum to coordinate around what’s the canonical take of your repo. That’s the second thing.

Then the third thing that we use Ethereum for is specifically around value flows. When we started the project we had two goals, one goal was to develop resilient infrastructure for software developers. Then the second goal was to actually enable more developers to make a living for their open source work 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.

We have a number of experiences that come there, but the Ethereum layer is actually completely opt-in. When you think about the Radicle architecture, these are the three things. Now moving to your question about governance. 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, this well-known defined 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 an admin on GitHub. We’ve been working with a number of teams that have been showing us what to do. It’s actually quite fascinating what they do today. Many of them maintain multiple GitHub organizations that pretty much mirror the same thing to go around the admin flow of GitHub.

Many of them regularly manually pin things on IPFS to make sure that okay there’s that too. Then they use their own website as the shelling point for coordination. Then on your own website, you will basically say, these are my repos. This is the latest of that. Radicle, really if you have a DAO, it allows you to coordinate and to decide on what is the canonical state of things through the coordination mechanism of your DAO.

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 and a theme, and we demonstrate the, you Y you know, move the SIGs, or even token based schemes are actually much more powerful than the classic admin flow that GitHub gives you.

So again we try to give tools to developers. We do not try to force a solution to everyone. You know, certain communities prefer to operate based on the benevolent dictator. That’s absolutely okay. You can do this in Radicle. Other communities basically would want some coordination of the peer to peer layer. Then you have obviously the decentralized world, the Web Three where DAOs right now are being really normalized and seeing a lot of users. We also allow them to control repos restlessly.

Alexis: I can dive a little bit 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 Bazaar model where you have multiple peers and in the application and the upstream client, you can essentially switch between different source trees based on which peer you’re interested in. In the network.

Let’s say you’re looking at the Radicle project itself, and you’re, Oh, I’d like to see Ele’s sourcetree, I’d like to explore that. Oh, I’d like to see cloud and source three. 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 gonna work the same way in the sense that you’ll be able to switch your view of a project to the org view, to the org source stream. 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 Elliot said. If it’s a, if it’s a multisig org than a Mo a multisig transaction will be executed, which will decide what the official org view of this project should be. 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.

Sunny: When you said, look at Ele’s source tree we mentioned earlier that like repos or projects don’t really have owners. 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 that happens to have Ele as the sole writer, but it’s not like his tree. Then he could take his fork and add more maintainers to it, so I could convert my fork into something that will eventually transition to being owned by an Ethereum DAO for example?

Alexis: I think you got it. Every peer or user on the system has full ownership over their own SourceTree or fork. It doesn’t mean they have ownership over the project. Which as I said, is owned by the maintainers or the single maintainer. Each maintainer, each contributor, each person who wants to just have their own copy of a certain project will have their own source tree.

Then it’s a question of trust. If I trust Sunny, then I will follow Sunny’s source tree. Be able to browse it. Maybe base my changes on, or build Sunny’s code into an executable. Because I trust them. It’s all about trust and obviously maintainers have a special status in the project. You may want to base your changes on their tree.

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. It’s not interesting to look at the words you use on a project, but if you do trust the org, because it’s, this project was created by this org, for example, then that’s something you would be really interested in having as your default view on a project. For example,

Sunny: 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, this project is still owned by this org. What’s different here than if you were saying, okay, this DAO has the rights to change it. How is this any different?

Alexis: It’s hard to wrap your head around, but basically on GitHub, a project is under a user or under an org and only under that user or that org. If the Tendermint code base is under the Tendermint org, it cannot also be under cloud head or under Sunny. That would be a, essentially a different fork of that project with a separate issue list. There is a canonical place where it lives under a certain hierarchy.

In Radicle that isn’t the case. The Tendermint project doesn’t live under the Tendermint org. You know, the Tendermint org may have anchored a certain view of that project on chain and say, this is Tendermint right. But another fork, Cosmos or Tendermint Two or whatever could do the same thing. It just depends on which, org you trust, and you will want to follow that orgs view of the project. Does that make more sense?

Sunny: Yeah, I think so one question I have then about the development process is what are your thoughts on how the, how will this affect UX? I have friends in college, we’re still learning computer science. For them, learning Git is always one of the most complicated things. This seems to make it even more complicated, and one of the things that having these like master repos helps is it also provides a canonical ordering.

Meanwhile, if like everyone’s like merging in patches from other people and like this, very secure scuttlebutt, swarm like way, causes all these like nightmares when it comes to things like rebasing, because like I’m different people are merging in other people’s code basis changes in different orders.

Alexis: Yeah. That’s a really good question. We said earlier that Radicle’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. In a peer to peer network, you have this inherent subjectivity. 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. Problems like merge conflicts could happen more often, especially if you have multiple maintainers. Because this is a case where you, as a contributor, want to contribute some changes. You pick one of the maintainers branch as the starting point to branch off of and create some changes, but it so happens that a different maintainer had a more recent copy of the repository.

That’s not something you knew because you’re, you’re not connected to that maintainer. There, you would have a problem that would not have arisen on GitHub, where there’s only one place to look at for the most recent change. There’s a couple of things we’re doing to improve that because it’s inherent to peer-to-peer networks because you have this asynchrony.

One of the things we’re doing, Ele mentioned it a little bit earlier is to have these seed nodes and seed nodes are very much like pubs and SSB. They’re essentially regular peers, but that are publicly available and always online. This acts a little bit like a point of coordination where there would not normally be one.

If you think of a completely peer to peer network, it’s messy. 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 points of coordination, the picture looks a little bit different because they and the maintainer of the 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 maintainer. It doesn’t really matter, but it’s just a server where you can push data to and pull data from. This really mitigates a lot of the problems with ordering essentially.

Sunny: One last DevEx question I have is for me, I actually do all my development on my laptop. I don’t have a desktop or anything like that. One thing that GitHub provides is this, always online storage and like available for anyone to pull from. How do you imagine, solving, providing these services to users? Are you guys working with any of the blockchain storage projects, Filecoin and SIA and whatnot, or do you guys have some other solution in mind for this?

Alexis: That’s an interesting question. I think on the one hand, the experience is local first. It means like all of the things you’re working with, all of the artifacts and everything is on your machine. On the one side you can work as you would usually whether or not you’re connected to the internet. What’s going to happen is if you push a change that you want others to see it’ll go through, but only once you reconnect to the internet or once you connect to certain nodes, will those changes be replicated.

The seed nodes function as data availability nodes. This is one way we can increase the replication factor of a certain project. Individual peers also work as replicators. 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 that to other peers and actually serve that content to other peers, even if I’m offering.

Sunny: By default, I start to host the data of every one who’s working on the same project as me?

Alexis: You have to add the peers you want to follow and replicate for now. It’s an explicit action.

Eleftherios: Yeah, exactly. What happened is that basically you have this social overlay, we call this, where you basically communicate intent around, I’m interested in this repo, so I’m going to track that. Then I’m also, I like Alexis, I trust Alexis, so I’m going to follow him. Then you have the social network that is basically emerging around that.

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 previous question. We’re also working on multi-device support, which is something that you mentioned that GitHub provides that for you today. This is something that we understand that for a lot of users is a real use case and we’re working on that.

Eleftherios: In terms of permanence, which was your question, we’re not really going beyond our peer to peer network yet. Although we continue to just monitor the space. It’s still quite early. I don’t know how much you have used most of the decentralized service providers, but it’s still quite early, but you know, both FileCoin, SIA, Arweave, Swarm? Like they all progressing quite fast. We think that at some point they will be more usable. You can imagine, again, an integration in certain seed nodes, for example. Like they take care of that. That’s something that we’re not working on, but we’re keeping an eye on to see how the space will develop.

Eleftherios: And then what we really think that’s going to happen is more of what happened with IPFS and pinning nodes. You, we think that basically, as Radicle sees traction, then there will be certain providers that will basically say, Hey pay me like if you dollars or if you crypto dollars and basically, I’ll take care of that for you. But we note on our side, we much more focused on making the peer-to-peer and the end user, the peer-to-peer network, the end user experience on the blockchain integrations, our work, instead of actually like trying to offer some of those things ourselves.

Sunny: Will this social overlay provide like some hurdles as well though. 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, I could be anonymous, and I can still open an issue or provide a PR. If there’s this manual peering that’s required, doesn’t this almost provide a higher barrier to entry for people to collaborate?

Eleftherios: It does. Absolutely. It absolutely does like our solution to this is again, seed nodes, meaning that you have these always own nodes that appear and what we think that’s going to happen there is that they’re going to have their own policies how they go about replicating data. Then additionally, you, as a user, eventually you will be able to configure how many degrees out you want data to propagate. You have these basically controlled switches leverages that you can tune into your own experience. The point absolutely stands it is about if there’s a higher barrier to entry, but also we think that there are ways around that. Alexis don’t know if you want to add everything on that?

Alexis: Yeah. Maybe one point is that the social overlay doesn’t have to be the same for all kinds of artifacts on the network. What I mean is maybe you’re replicating that maybe that the peers in the source trees you’re replicating are chosen manually. But you can be open to receiving pull requests from any user as long, of course, as you are aware of those changes. Since the Radicle network is essentially a gossip network, things of interests are broadcast and essentially flood the network in that way.

Peers get to know about a lot of things that they’re not necessarily interested in. Oh peer X created a new branch, and it’s, Oh, well, I’m not tracking this project. I’m not following this project. I don’t care about that, but I still know about it. I think for things like issues being open by some anonymous contributor or PRS or things like that, maintainers could choose a policy where it’s, 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.

Alexis: That then the maintainer can look at it and either discard it, or actually 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, let’s say, promiscuous policy, where everything is visible and replicated could lead to the opposite problem where yeah. You have sybil attacks and spam issues and abuse and things like that. It’s kind of, it’s a line to tread, given that there’s no like moderators or moderation in the network apart from individual user blocking or following.

Brian: Okay. Let’s move to, I think the last thing you guys mentioned in terms of what Radicle is providing, and I think you mentioned that in there in the concepts of open source sustainability, another phrase I’ve seen in some presentation of yours that it’s a nice way of looking at it is DevFi developer finance, a play on the current defy hype or boom. Can you, let’s say, Radicle succeeds, what does that change in terms of business models around open source? Yeah. The sustainability of open source development.

Eleftherios: That’s a great question. Yeah, the DevFi. It’s more a meme internally for now, but, we’ll see for this capstone. Talking about sustainability today, the solutions that developers have are, again mainly constrained to the platforms, first of all. Then in terms of the solutions you have are very limited. You have a small minority, it’s a small market around by bounties, that’s one model that you see in the industry, the second model that now is getting more attention because of GitHub and the Patreon \ GitHub sponsors \ OpenCollective. I’m simplifying things. There are some small differences between each and every one of those, but you can think of this more like a donation type of model in exchange for something. That’s the second thing.

Then the third model that you have is really starting a company. Then if you started the company, then what can you do? Usually if you want to continue developing open source, then you do open core most of the time. Which it is the model that for example GitLab is using and a lot of different providers use.

The idea here is that you have an open source code base at the center, and then he developed paid features around that. Then it could be paid features. It could be consulting this again, ranges. Then you also have the software as a service type of thing that you subscribe to some community edition. This is where the world is today. What we really think is that blockchains fundamentally like bringing innovation around value.

That’s why we think that right now the current trend with DeFi makes a lot of sense simply because you just have this new playground to design your financing models and new value flows while also doing this in a trustless way. We’re looking to introduce a number of these experiences.

We really think that this is not the right time to just say, this is going to be the model that, when we look at the developer space, we see a number of different ones. I’ll mention some that we think are interesting ones. The first thing that we’re working on is something that we call Radicle lists. This is basically a social experience around giving the way that it works is, as an open source supporter, you can set the budget and you can say, I’m interested in supporting Open Source with 1000 DAI or another stable coin.

Then what you can do is you can actually start curating a context specific lists, for example one prototype we have Vitalik curating a list of ETH 2.0 researchers, or the best projects needs to point out, for example. Now what you start doing is you basically started streaming your funds towards your lists.

Additionally, anyone that basically lands on your profile can actually now see that these are the lists that you have curated, and then also started supporting you. It’s a little bit like Awesome lists, like Awesome React or Awesome Python, these things that live on GitHub that developers curated the set of resources. Now you can imagine the same thing with money, where basically you can have the best projects within the Cosmos ecosystem.

Now anyone can actually see them pass them around, support them. You can basically support these projects. 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 is designing a feature that we call backend issue.

It’s a bit like GitHub meets Kickstarter. Within your issue tracker, as a maintainer, you can say, Hey, I’m only going to work on this issue. My support there’s basically pooled together 1000 DAI right. In addition to that, again, because we’re using blood and we think blockchains are a better tool for aligning incentives.

What we do is you can have schemes where, for example, 50% of the funds are released upfront and 50% after a milestone has been reached. While today on existing platforms is all or nothing because of the way the technology they use work. On Kickstarter, all the funds are at least up front. You can engineer this in a very flexible way. These are the two things that we are actually starting with now.

Additionally, there are a number of other things that are going on in the space that we, and we’re keeping an eye on, for example, this year, you see a lot of attention around non fungible tokens on Ethereum. We have a number of ideas about non-fungible tokens, where you as a supporter, for example you support an open source project in exchange, you get a non-fungible token.

Within the experience, now you have a special staff. There’s like a bit of, you can think of it as a special pass. Then additionally, you have certain functionality within the repo. For example, imagine only your supporters will be able to actually prioritize your issue tracker or potentially only your support. Theirs might be able to access an issue tracker for example.

There are all of these like interesting experiences that bring value closer to the co-collaboration experience. Now these are now like available. We’re looking at introducing some of them, and then maybe the final one that we’re looking at this idea of social tokens.

It’s quite interesting because we’ve been like talking a bit about this internally, and it’s so interesting that there’s something very intuitively very viral like we were joking about this in one session and then immediately you could see that theme started talking about, Oh yeah, I’ll send you 10 clouds for cloud, for example.

There’s something there that’s very playful. Again, if you combine this with some form of utility within the repo, we think that they, something very interesting, but 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, GitHub now is becoming a place developers will be starting their own companies. Their whole organization will live in one of those companies.

We really want to actually take that to the extreme and see like observing what is interesting is going on. What is interesting on the Ethereum world, on the DeFi world, and then repurpose those, bringing them back to the developer and basically allow developers to make a living. 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.

Brian: Last question, Alexis. I remember even in the beginning, when we met you were working on as a hobby on some Bitcoin client, for the longest time, you guys were actually thinking of creating your own blockchain for a Radicle based on proof of work, which was a very contrarian thing. Where basically everyone was going to be new blockchain turned on various types of proof of stake systems. Maybe it can be smart contracts, and now you guys are building on Ethereum as well. I’m just curious to hear, what is your thinking personally on the role and importance of Bitcoin as well as the role and importance of Ethereum?

Alexis: Yeah, sure. I mean, that’s like a very open-ended question, but I’m going to try to say smart things. The first thing is that Ethereum offers us things that are hard to do without. We mentioned at the beginning, stable coins. Developers want to receive donations or support and pay support using stable coins. That’s something that at the moment only Ethereum really offers the problem.

The reason why we originally wanted to build a proof of work chain is for security. Because we were doing this os rank thing that we just mentioned on chain. You can’t do that as a smart contract, it’s too expensive. It needs to happen on layer one, essentially. We were exploring proof of work due to the requirements of having a light client.

One of the things I still really dislike about Ethereum is the centralization around things. Today, it’s impossible to run a full node on your laptop or even on your desktop, and there are no real light clients that are usable. Part of this is because the light client technology is even though Ethereum is a proof of work chain at the moment, still creating the right proofs for a system that allows complete freedom and programmability is really hard.

One of the things I would like to see is actually some integration of Bitcoin into Radicle, maybe something around the lightning network to do instant payments for very cheap to developers. Something that on Ethereum is looking more and more problematic due to the price of gas.

I think in the end, we’re going to see Ethereum shining for its connectivity and integration of all the different kinds of smart contracts, the liquidity around all these different tokens, the programmability, the ability to even maybe connect your donations to something like compound to gain some yield and things like that.

You can do really interesting things, but for simple payments, for cheap payments, I’m still looking at things like lightning and for people who are also paranoid, or don’t want to trust a third-party to verify payments again, something like Bitcoin enlightening would work better. In my opinion.

Eleftherios: Maybe if I can add on that. Yeah. I think everything Alexis said is right. The point that I want to communicate here is that we not, Max’s like we’re not maximalists. We really like to see value in different approaches. We have a specific vision that we’re going after. We realized through user sessions that this vision is relevant to a lot of people, not only to the Bitcoin or Ethereum community, but also to other blockchain ecosystems.

We have a lot of friends that are excited about us on the cosmos ecosystem, for example, same story with of the, so all I’m trying to say here is that we have certain principles in mind, but beyond those principles, we really like try to see what is needed and like what is requested from our users. Then basically work around that, obviously one of the benefits that we see with Ethereum is that we feel that right now, everyone will interpret with Ethereum.

I immediately Ethereum opens you up to this wider developer ecosystem, but as  Alexis said there’s also trade offs there. We really keeping our eyes open, really working with our users. Then if what we’re working on is relevant for more, and this is something that our users want, we will actually work on that then and bring that to more ecosystems.

Brian: Cool. Well, thanks so much for joining us today, guys, it’s been great to hear about the progress and to see the upcoming Ethereum integration and I am really excited.


  • 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/1inch

0:00:00 | -:--:--

Subcribe to the podcast

New episodes every Tuesday