27 comments

[ 2.3 ms ] story [ 51.9 ms ] thread
The more I have been using git and building my own tooling and services around it for usage, I have figured out that something like radicle feels like the right/better solution, definitely better than what github is atm.

There are rough edges and the seeding thing is a bit mehhh. And honestly there are a bunch of things I would do differently but I like the spirit of things.

Not sure where the authors of the project stand, but it's fun to see them make progress.

Love to see it. Unlike tangled.org this is local-first and has a solid story around private repos. I’m bullish on distributed forges in general, but I’m all for experimentation in figuring out exactly what that looks like.
I like this idea a lot! I need to find people to try it with, though, which is not so easy with GH being so popular :-(

Some nitpicks:

* What is with the forced serif font on the website?

* Does this support other version control systems? Like mercurial, SVN, pijul, etc.?

How well does it hold up under load? What are the CI and PR stories?
Radicle is really underrated, especially when working with agents. I find it a joy to use for my agentic workflows.

If there's purely an agentic forge one day, it's likely going to be a distributed one, with cryptographic identities and signed artifacts by default.

radicle is awesome and Just Works from what I've tried of it
I'd like to see radicle replace crates.io. I can't get over Rust's dependency on github/Microsoft, and I can't get over the lack of namespacing.

All you would need is cargo compatibility, and a trusted namespace that kept up with the metadata of the current contents of crates.io, right?

edit: I really, really like rust, and love basically all of their choices about the language, but I can't stand the feeling that I'm being tricked into an ecosystem dependent on one of the worst behaved companies in the world, and I can't stand that a lot of rust projects smell like GPL-washing.

That being said, git is GPL and radicle is MIT, so it feels like the same thing, but Github also ain't git. I prefer MIT to MS; if radicle gets important enough and decides to rubpull, there will inevitably be a Free fork anyway.

* crates.io is moving away from GitHub-only authentication

* crates.io's attachment to GitHub is a fact about crates.io specifically, not the Cargo crate registry protocol

* Cargo's support for Git repositories is generic across Git and has nothing to do with GitHub specifically

* Radicle offers nothing to a crate registry that a Git remote doesn't

* and none of this has anything to do with the GPL.

It feels like you're just listing off things you like and don't like aesthetically. They have nothing to do with each other structurally.

I tried to understand what this does...

> What is Radicle? How is it different from Git/GitHub?

> Radicle is a peer-to-peer code collaboration platform (“forge”) built on Git. Unlike centralized platforms like GitHub, there is no single entity controlling the network or user data. Repositories are replicated across peers in a decentralized manner. Radicle is an alternative for people and organizations who want full control of their data and user experience, without compromising on the social aspects of collaboration platforms.

(Quote from their FAQ).

This isn't even trying to answer the titular question... None of them, actually.

So, what is Radicle? A platform built on Git? What does this mean? A platform for what? What is it for?

Why Git/GitHub are used as if they were the same category of things? There's not even an attempt at answering the "how is this different from Git?" question. What does it offer that Git doesn't? Wtf is "forge"?

Radicle is an alternative... to what? I believe I have full control of my data in my Git repository... why do I need an alternative with even more control? How will I have even more control?

* * *

Maybe whatever this software does is actually useful or even good, but the documentation can't be worse.

I wish they would make local-only deployment easier. For example, lets take 3 machines and try to setup Radicle to work only on those, without joining the common Radicle network. Like on-premises GitLab, but decentralized, without the need of the server. It requires quite some serious scripting and usecase not covered in the documentation.
Same here... I have been looking at all the self hosting options for a while but swapping one centralized system for another isn't what I would prefer. Running/using local and community gitea/forgejo has been good, but I hope decentralized radicle could be the solution to more independence.
I patched my local radicle to remove the default seeds, and I can put my own seeds as default. It is pretty easy to script some commands that auto add your local nodes when init a repo.

I also added some network rules to block non-local network access to radicle. Not needed but I really wanted it to work only on my lan.

Works great. I setup several skills for agent harnesses and they use radicle + jj + git perfectly. It is fun watching issues pop up and monitoring progress via the flow.

I am building more tools around this workflow because it is so effective. Radicle acts as the long term project memory bank and management. I can write issues and they can automatically be picked up.

What I'm adding is making the issues more searchable and an agent proxy that integrates radicle into calls. among other things.

This is all pretty straight forward to do, I really recommend it.

Congrats!

Maybe I'm not the target audience for this, so pardon my ignorance when I ask what problem does this solve? Centralization and censorship?

I discovered Radicle back in 2020 (when their website looked incredible: https://web.archive.org/web/20201201030505/https://radicle.x...). I bounced off of it, in part due to being unable to effectively delete repositories. They used to have an FAQ about that—looks like it's gone now, though the public-private repository area is much more fleshed out (you can make a repo private, in which case no new updates will be publicized but the history will still exist). In truth, it's just profoundly difficult to effectively "delete" things in a decentralized system (see: Matrix, BitTorrent, et. al.). But definitely something to consider; people accidentally upload secrets, and want to have some recourse when that happens.

Still, time has passed and I have become more interested in GitHub alternatives (https://figbert.com/posts/ideating-tragit/). Will likely end up moving to Tangled. But first I need to add support over there for pushing over HTTPS...

I have two questions:

1. Does Radicle also work over TOR? 2. Does Radicle support Git LFS and/or Git Annex?

How do these federated forges deal with spam? If merge requests and issues are federated, does that mean that anybody running a radicle node (or interacting with one) can open issues or merge requests on all the repositories that you've made public? Or is there a whitelist (or something fancier?) to allow interaction only with specified nodes?
Unfortunate that they aren't using the AGPL license. It will allow SAAS companies to Embrace, Extend, and Extinguish.

Indeed, this seems to be already planned. https://radicle.dev/faq "Radworks intends to offer services built on top of Radicle."

I saw https://radicle.dev/2025/08/14/jujutsu-with-radicle at the bottom of the homepage and assumed it meant Radicle was planning to support a native jj protocol to decentralize jj repositories. That's unfortunately not the case.

Is there a plan for jj repositories in radicle proper? I'm very tired of git shortcomings.

Maintainer of Radicle here.. Currently, we are focused on building on top of Git, and that is very much baked into the protocol design right now.

We will benefit from jj's compatibility with Git for the time being, and seeing how that evolves.

Interoperating with jj's repository would likely be a bigger task and it is still evolving quite quickly itself.

Somehow never heard of this before. It's even packaged in NixOS so I'll probably set up an always-on node.
The story for sensitive/proprietary repositories doesn't feel well-fleshed-out yet:

> Radicle supports private repositories that are only shared among a trusted set of peers, not the entire network. These are not encrypted at rest but rely on selective replication and are thus completely invisible to the rest of the network.

There's no structural separation of public / private repositories; this is one bug or fat-finger away from a leak.

I was looking into how to get a radicle node running, but connected to only my own devices.

You can't seem to start the radicle node without it automatically connecting to the (generously provided) global shared seed nodes, and you can't examine/change the config without starting the node (at least with rad subcommands).

If you do `rad auth` and then delete the four seed addresses from ~/.radicle/config.json before starting the rad node, it helpfully re-adds them on startup:

  [...]
  INFO  node     Opening node database..                                                                                                                                                                           
  INFO  node     Address book is empty. Adding bootstrap nodes..                                                                                                                                                   
  INFO  node     4 nodes added to address book
  [...]
(It doesn't add the bootstrap nodes if I instead add a seed "<randomDID>@10.254.254.254:8776".)

Is there a guide to using Radicle like one might use Fossil within a small company / within a small group of people (disconnected from the iris/rosa radicle.network seeds)?

This is cool. I think it fits the Agentic model a lot better; wrangling PATs and repo permissions on GitHub is quite tedious.

How are folks wiring up CI/CD? Seems you want to trigger compute DAGs on the patches you receive, what’s the latest and greatest here?

One challenge with distributed systems is that deletion and rollback expectations differ from traditional centralized platforms. Even if a platform removes data, cached or replicated versions can still persist elsewhere.