Live data from Hacker News

Radicle: Sovereign {code forge} built on Git

radicle.dev

51–60 of 101 posts

Re: Radicle: Sovereign {code forge} built on Git

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

Re: Radicle: Sovereign {code forge} built on Git

#52

Earlier quoted context omitted.

> So, what is Radicle? > Radicle is a peer-to-peer code collaboration platform (“forge”) built on Git. ----- > Why Git/GitHub are used as if they were the same category of things? They are not. Github is a centralized collaboration platform built on git, and radicle is a peer-to-peer collaboration platform built on git. ----- > Wtf is "forge"? A word some people started using for the class of Github/Bitbucket(RIP) or…

> To Github, or other "forges." Then why do they bring Git into the picture? They are not comparing themselves to Git... > Radicle is a peer-to-peer code collaboration platform (“forge”) built on Git. This is a word salad that means nothing... more than 99% of moderns software is built on Git in one way or another. Anything that is designed to be used by more than a single user could be arguably called a "collaborati…

I did understand the question. I think you're somehow confusing "built on git" with "we used git while we built it." But that's honestly just a weird guess. I really can't figure out how you could be confused about any of this.

I hope the definitions shared in the sibling comment will help.

> Then why do they bring Git into the picture? They are not comparing themselves to Git...

I would find it very strange if Github didn't mention git. It would be equally strange if radicle didn't mention git. They both wrap git.

Re: Radicle: Sovereign {code forge} built on Git

#54
post #53

I have two questions: 1. Does Radicle also work over TOR? 2. Does Radicle support Git LFS and/or Git Annex?

1. yes, it's in the user guide [1] 2. Git LFS should work, yes. Care to try and report back ? ;) Open a new topic on the Zulip #Support channel [2] if you run into any issues.

[1] - https://radicle.dev/guides/user#4-embracing-the-onion [2] - https://radicle.zulipchat.com/#narrow/channel/369873-Support

Re: Radicle: Sovereign {code forge} built on Git

#55
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?

Re: Radicle: Sovereign {code forge} built on Git

#56
post #43

Earlier quoted context omitted.

I don't understand why you'd want them to built another CI system. Just for the sake of it? Feels like using a free Jenkins gets you everything you want. Doesn't need more than a container or Java either.

That's also perfectly fine if that's what it is. I would just phrase that as "They don't have CI but they provide hooks."

it's a little of both: on the one hand we're working on CI integrations (through generic webhooks or CI-engine-specific adapters that basically implement the CI engine's API [1]), so you can keep on using your existing CI solution. On the other hand, yes, there is also work towards a new CI engine (Ambient [2]), which aims to make it safe and secure to run CI on other people's code, which is important when working towards a distributed, community-ran, CI system. We should have more docs regarding the CI story up on radicle.dev in the next week or two.

[1] - https://radicle.network/nodes/index.radicle.garden/rad%3Az3G... , [2] - https://ambient.liw.fi/

Re: Radicle: Sovereign {code forge} built on Git

#57

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

I read that it works well with jujutsu

yup ! https://radicle.dev/2025/08/14/jujutsu-with-radicle

Re: Radicle: Sovereign {code forge} built on Git

#58
post #55

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?

yes, we currently have just the base building blocks (`rad follow` - allowlist / `rad block` - blocklist) for the fancier things to be built on. When you "seed" a repository, by default you seed it only with "followed" scope, which means you would only see issues and "Patches" (our term for PR/MR) from the repo maintainers + other peers you follow (i.e. in your allowlist).

Re: Radicle: Sovereign {code forge} built on Git

#59

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?

In a nutshell, I summarise it like this: I see Open Source Software is a public good. As a public good, it doesn't belong in any proprietary platform, nor should orgs of any kind be in a position to gate keep it. We should rather host it on a public, peer-to-peer network that everyone can have access to.

Re: Radicle: Sovereign {code forge} built on Git

#60
post #30

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.

A containerised deployment would (understatement warning!) be useful.

This is a good fit primarily if you want to run a Radicle node that only seeds repos you tell it to. If you want to write code which you publish on Radicle, you need the tool that signs all your work with your private key (of your Radicle identity) - i.e. the `rad` CLI - and running that in a container isn't very useful. (e.g. think about how you'd replace `rad clone`). Having said that, here's a container image I maintain, in case it helps: https://quay.io/repository/radicle_garden/radicle-node
Post reply on HN