Live data from Hacker News

Radicle: Sovereign {code forge} built on Git

radicle.dev

91–100 of 101 posts

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

#91

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-fin…

Radicle contributor here.

When a repository is initialised as private [1], it's encoded in the repository identity document. The only way to change a repository to be public is to update the identity document; in the case of a repository with multiple delegates (repo maintainers in Radicle nomenclature), such a change requires a quorum to be met. So I'd say it's more than a fat-finger away from leaking.

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

There's an open proposal [2] to introduce the concept of network configuration that would help with these kinds of use cases. Moreover, we're working on other ways to improve the collaboration experience for small teams, so stay tuned and thank you for this feedback!

[1] https://radicle.dev/guides/user#initializing-a-private-repos... [2] https://radicle.network/nodes/iris.radicle.network/rad:z3trN...

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

#93
post #31

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…

Does radicle have some way of storing binaries outside of the source tree? I know cargo compiles from source by default, but AFAIK it can (and does) download binaries as well.

radicle-artifact is currently under active development: https://radicle.network/nodes/iris.radicle.network/rad:z4VYy...

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

#94
post #53

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

Regarding 2, we're actively working on radicle-artifact as an alternative to Git LFS with transport agnostic distribution (https/p2p), attestations, and redactions.

https://radicle.network/nodes/iris.radicle.network/rad%3Az4V...

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

#95
post #29

Earlier quoted context omitted.

AD: Feel free to post on our Zulip [^1] about your experiences of agentic workflow if you haven't already! Some of the team are interested in developing the agentic workflow experience. [^1]: https://radicle.zulipchat.com/

I am surprised you don't use RustChat[1] [1] https://rustchat.io/

[flagged]

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

#96
post #72
post #70

Earlier quoted context omitted.

Zulip used to have a really neat feature where you could open up certain channels to be indexable by search engines. Basically turning it into an open forum. The feature is still sorta around but completely broken. Quite unfortunate imo. It was a really neat solution to the walled garden problem with team chats

Zulip product lead here -- I'm not aware of anything in this space that used to work and no longer does. There's long been a way to make Zulip channels searchable with zulip-archive ( https://github.com/zulip/zulip-archive ), and that continues to be available. Making the app-native web-public channels accessible to search engines is a big technical project, tracked as https://github.com/zulip/zulip/issues/21881 .

Ah thanks for the correction. For some reason I mixed up Zulip with Linen.dev

https://www.linen.dev/

I guess this feature has been requested for Zulip for a long time

https://github.com/zulip/zulip/issues/21881

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

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

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.

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

#98

Earlier quoted context omitted.

* 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…

> crates.io is moving away from GitHub-only authentication Crates.io has not moved away from Github-only authentication, and got into the habit of yelling at people who complained about it. > crates.io's attachment to GitHub is a fact about crates.io specifically, not the Cargo crate registry protocol Is this just trivia you wanted to share? I feel like I covered it in the second sentence of the comment you're replyi…

Thank you for repeating yourself in exactly the way I was criticizing without really reading the criticisms. So, once more with feeling: Radicle does not offer the Cargo crate registry protocol. Radicle does not offer anything to do with crate hosting that a generic Git remote doesn't. If you want a crate repository like crates.io, you do not want Radicle. The best crate repository software is Cloudflare's Freighter, but if you were to implement some sort of distributed version, that's also an option, but it wouldn't be called Radicle. If you just want the Git support that Radicle offers, you can do so just fine without Radicle; it is generic Git remote support, and you can declare Git dependencies in Cargo.toml from Sourcehut or Codeberg or whatever. Radicle is a product that puts issue/PR tracking on top of Git. It does not have anything to do with what separates git dependencies from crates.io dependencies, it does not have anything to do with automatically mirroring existing hosts, it does not offer anything to the git dependency experience, and it does not offer anything to the registry dependency experience.

> Crates.io has not moved away from Github-only authentication, and got into the habit of yelling at people who complained about it.

This was me updating you on the present state of the world. Replying with the previous state of the world, as though this is somehow new and better information, without even looking up whether it was still true, is a level of deliberate ignorance I can't fathom displaying on purpose. Again: crates.io is presently in the process of moving away from GitHub-only authentication.

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

#99
post #67

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.

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

#100
post #69
post #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…

It’s a fair point about the difficulty in deleting data in a decentralised system but that’s also true in more centralised systems like GitHub or any other website. Once some data is out there, you have no control over whether it can be removed. Other parties could have copied it and may re-share it. “All” removing data from a centralised system does is slow down this spread, sometimes to the point that it is effecti…

Well said, in particular the last sentence: IIRC at the time I was seeking to delete a repo that I had made accidentally so as to clean up my profile.
Post reply on HN