Radicle Desktop released
The Radicle peer-to-peer code collaboration project has released Radicle Desktop: a graphical interface designed to simplify more complex parts of using Radicle such as issue management and patch reviews.
Radicle Desktop is not trying to replace your terminal, IDE, or code editor - you already have your preferred tools for code browsing. It won't replace our existing app.radicle.xyz and search.radicle.xyz for finding and exploring projects. It also doesn't run a node for you. Instead, it communicates with your existing Radicle node, supporting your current workflow and encourages gradual adoption.
LWN covered Radicle in March 2024.
Posted Jun 21, 2025 8:11 UTC (Sat)
by simlo (guest, #10866)
[Link] (7 responses)
Personally, I don't want to host anything myself, and therefore just push things into Github to get backup and free CI. Then I also know people can access my code if I ever get open it. But I would like a way to get metadata out of Github again, and adding it to the Git report is an excellent idea.
Posted Jun 22, 2025 7:35 UTC (Sun)
by qyliss (subscriber, #131684)
[Link]
There are already projects that do this, for example https://github.com/git-bug/git-bug.
Posted Jul 1, 2025 20:38 UTC (Tue)
by massimiliano (subscriber, #3048)
[Link] (5 responses)
One year has passed, but my take on this apparently still stands... so I repeat it.
Disclaimer: Radicle is very dear to me mostly because I worked full time on it for most of 2020. I have been following it since then but I am no longer active in the project.
I have a few main gripes with it:
Posted Jul 2, 2025 8:36 UTC (Wed)
by yorgos (guest, #178135)
[Link] (4 responses)
> it should use plain, eventually centrally hosted git repositories as backing store for "nodes": this would allow existing git projects stored anywhere (including github, gitlab and other forges) to join the Radicle network as valid node copies, even if they cannot speak the p2p gossip protocol, mostly eliminating the barrier to entry for new users
Can you please elaborate a little on this point? I specifically don't understand "this would allow existing git projects stored anywhere (including github, gitlab and other forges) to join the Radicle network as valid node copies". How can a git project (repo?) join the network on its own (without some piece of software like `radicle-node` ? What is a "valid node copy"?
> peer to peer is nice to have decentralization, but should be confined to the role of a sort of "signaling" layer (so that online clients are informed of changes), while the actual data would be hosted on plain git repos
isn't the actual data in `$RAD_HOME/storage` [1] basically a list of (bare) git repos ? What does radicle do on the p2p layer that is different than what you'd expect / prefer?
> it should have properly decoupled user and node identities from the start: any user might want to use multiple developer workstations and still keep their identity; not supporting this use case also raises the barrier to entry "too much" for most potential users
I agree that this is still a missing piece. Work is ongoing [2] however, and word on the radicle zulip [3] is that there will be more progress on this within the year.
[1] - https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3trNY...
Posted Jul 3, 2025 12:02 UTC (Thu)
by massimiliano (subscriber, #3048)
[Link] (3 responses)
While designing Radicle, I noticed the following:
So, to be clear: the system would still need a p2p network of nodes, that would be the primary interface for discoverability of:
Anyway, this p2p network would not strictly need durability (all the data is already out there, accessible in durable public git repos). And the amount of needed storage (or memory) would be negligible compared to the needs of the actual git repos. From an operational standpoint it is way more manageable than the current Radicle design (at least, IMHO).
The most important thing is that to join the community, a new user would only need to add the appropriate metadata to their existing public git repos, and announce them in the p2p network so that they can be discovered. The barrier of entry would be much lower, the actual durability guarantees would be high, and the global impact of the project (in terms of consumed resources, like machines and electricity) would be optimal because large-scale data centers are engineered for that, there's no way for an ad-hoc p2p network to me more efficient than them.
I tried hard to convey this vision in the early design phase of Radicle, but I failed.
Posted Jul 3, 2025 13:00 UTC (Thu)
by paulj (subscriber, #341)
[Link]
It would be good if one of the bits of meta-data in the git repo could be a (optional) list of native git sources of the repo.
Would be a really nice add-on over git.
Bonus points if the P2P service can also cache and do content-addressable distributed caching of the git objects over (willing) nodes. Though, perhaps that kind of feature is precisely why radicle does /not/ use existing git repos as its storage?
Posted Jul 7, 2025 9:34 UTC (Mon)
by yorgos (guest, #178135)
[Link] (1 responses)
I'm not sure I quite understand this point, but perhaps it's not that important.
> The "cost" of operating a node, and especially the cost of guaranteeing proper data durability, is nontrivial. While it is true that the p2p network provides redundancy, there are no guarantees that peers will actually exist. Right now, if I want to ensure the durability of a git repo I care about, I just push a copy of it to github and I am done. This does not work in Radicle, unless I deploy nodes using a storage that guarantees that durability.
Or unless *others* run nodes that provide this storage for you (e.g. permissive seed nodes). Which is the same situation as with GitHub, et al. You're leaving the durability of the git repo you care about to a 3rd party.
> More generally, at a global level, it is more cost-effective to implement a desired degree of durability in a properly designed data center (like the ones used by github and other git-storage providers) than hoping that durability will magically happen in a p2p network.
Does Radicle prevent that?
> The most important thing is that to join the community, a new user would only need to add the appropriate metadata to their existing public git repos, and announce them in the p2p network so that they can be discovered. The barrier of entry would be much lower, the actual durability guarantees would be high, and the global impact of the project (in terms of consumed resources, like machines and electricity) would be optimal because large-scale data centers are engineered for that, there's no way for an ad-hoc p2p network to me more efficient than them.
There's quite a lot of context missing here, I think, but, if I understand correctly, this assumes we can convince the existing service providers to run radicle vs. just plain git. (Otherwise I don't understand how "adding the appropriate metadata" would allow information to be announced to the Radicle network). Depending on whom you ask, this may seem like a much bigger "barrier to entry" (they are happy with their existing forge software).
But I do agree, that we should try to get existing service providers to run Radicle nodes that announce information on the network! Such service providers can even provide *custodial* radicle nodes for their users (where their users' keys are held by the service provider - basically similar to how BlueSky works (without a Personal Data Server) and this would allow users to use Radicle through the web - without having to run a node on their machine.
Disclaimer: I am actively working on bringing one such service up online soon, so I am obviously a little biased! ;)
Posted Jul 7, 2025 14:08 UTC (Mon)
by massimiliano (subscriber, #3048)
[Link]
I try to mix my replies to your quotes, I hope the result will be clear...
It's not so important.
My main point is that "others" are not likely to run Radicle nodes "at scale". Not soon, not at "github scale", and not as efficiently as plain git repos.
Just adding the metadata would not be enough: the "repo node" would need to be explicitly announced on the p2p network, which will track its state and relay it to the other nodes.
My point is that we should not put ourselves in the position to wait for that!
I understand the intent "let's hope that many users will also run open and permissive nodes so that the global Radicle network capacity will be large enough to take over the world".
Call me a pessimist, but I am convinced that we'll never get there, mostly because of the enormous collective cost.
On the other hand, large-scale providers are already offering plain git hosting for free.
By designing Radicle to leverage that, I thought we could have a chance at conquering the world.
Too radical
Too radical
Too radical
Too radical
[2] - https://app.radicle.xyz/nodes/seed.radicle.garden/rad:z3t...
[3] - https://radicle.zulipchat.com/
Too radical
Can you please elaborate a little on this point? I specifically don't understand "this would allow existing git projects stored anywhere (including github, gitlab and other forges) to join the Radicle network as valid node copies". How can a git project (repo?) join the network on its own (without some piece of software like `radicle-node` ? What is a "valid node copy"?
(these two things are almost the same thing, or anyway they are strictly related)
Too radical
Too radical
For any software I run on my machine, I'd **absolutely** want to be in control of what it stores on my machine. I'd hate for other users I don't know/trust to be able to push commits with malicious content and have that stored on my machine - and seeded from there to the rest of the network.
Service providers can still run hosted Radicle nodes in their data centers and offer that as a service to other users who don't want to run their own infra. There seems to be an assumption here that a p2p technology excludes nodes that are running by professional service providers, in data centers. I don't think that will be the case at all - in fact, I *expect* that service providers will have an important role to play in the network.
Too radical
>
I'm not sure I quite understand this point, but perhaps it's not that important.
For any software I run on my machine, I'd **absolutely** want to be in control of what it stores on my machine.
The idea is that in git repos (Radicle or not) the "owner" adds contents using push operations, and receives contents from others with pull (and, when necessary, merge) operations.
This is true in radicle nodes, but it is also true for any "plain" git repo, which is why in my proposal Radicle git repos would be usable (they would allow push and pull operations) even if the p2p layer does not provide git storage at all.
>
Or unless *others* run nodes that provide this storage for you (e.g. permissive seed nodes). Which is the same situation as with GitHub, et al. You're leaving the durability of the git repo you care about to a 3rd party.
>
(Otherwise I don't understand how "adding the appropriate metadata" would allow information to be announced to the Radicle network)
In my idea the p2p network is still there (otherwise there's no decentralization), but its scope is very limited.
Particularly, it does not store git objects at all.
It only stores repo URLs, ref hashes, and user references (public keys and URLS to the "root user repo" that holds only the user metadata), and its only task is to index and relay this data.
>
But I do agree, that we should try to get existing service providers to run Radicle nodes that announce information on the network!
IMHO, large-scale providers like GitHub will never host Radicle nodes: it is against their own interests.
They do host plain git repos for free for open source projects, but they do so only because this increases usage for their platform as a whole.
And, again, IMHO, the global cost of hosting Radicle nodes for, ultimately, all the open source projects currently publicly accessible using git, is just too high.