[HN Gopher] Radicle: The Sovereign Forge
___________________________________________________________________
Radicle: The Sovereign Forge
Author : ibobev
Score : 241 points
Date : 2026-01-23 13:25 UTC (9 hours ago)
(HTM) web link (radicle.xyz)
(TXT) w3m dump (radicle.xyz)
| endiangroup wrote:
| AD: Newly joined protocol dev here, feel free to ask questions!
| a-french-anon wrote:
| Hello, I read the FAQ and didn't manage to find (perhaps my
| fault) if users had to store data they didn't
| explicitly/manually cloned; like Freenet. Is it the case?
| endiangroup wrote:
| AD: You have control over what you seed, if you are a
| permissive node you accept all content on the network, but by
| default your local node will only seed what you instruct it
| too.
| lorenzleutgeb wrote:
| No. Please refer to https://radicle.xyz/guides/user and read
| this to understand the concept of "policies". This should
| answer your question, but otherwise of course I am happy to
| explain further.
| Tepix wrote:
| This sounds pretty cool, can I do pull requests across radicle
| instances?
|
| gitlab recently closed a 2015 feature request
| https://gitlab.com/gitlab-org/gitlab/-/issues/14116
|
| PS: What's this "AD" prefix you're using?
| endiangroup wrote:
| AD: Pull requests are `patches` in radicle, when you clone a
| repository you create a git namespace for yourself from which
| you can edit to your hearts desire, you can then open patches
| to other repos via this mechanism.
| nh2 wrote:
| Are you open to rename the "patches" terminology?
|
| Apparently currently "1 patch = 1 pull request of e.g.
| multiple commits" in Radicle.
|
| That confusing, since in Git a patch usually refers to a
| single commit: * git format-patch outputs
| 1 ".patch" file per commit. * Its output also
| enshrines that, in the subject lines that appear e.g. on
| Linux mailing lists: "[PATCH 1/2]", meaning "one of two
| patches in a patch series".
|
| (That said, `git format-patch --stdout` can concatenate
| multiple commits into a single output, but it does not
| offer to write those into a single .patch file by itself.)
|
| So when reading "Patches", I was intuitively unnecessarily
| scared that the tool cannot handle whole branches, and
| flattens out all commits.
|
| Maybe "Patchsets"?
|
| That's what kernel people apparently call them:
|
| https://kernelnewbies.org/PatchPhilosophy#What_is_a_patchse
| t...
|
| https://kernelnewbies.org/PatchPhilosophy#Patches_are_git_c
| o...
| happosai wrote:
| This sounds really, really cool. How does reviewing such
| patch-PR's work?
| endiangroup wrote:
| AD: The prefix is my initials :) - my only HN account is a
| shared one with a co-op organisation I work through. I use AD
| to distinguish who's commenting... however my co-workers have
| yet to use this account ha!
| pseudalopex wrote:
| Your initials form a word used as a disclaimer often. And
| shared HN accounts are not common.
| nh2 wrote:
| If you replace "AD:" by "Adrian from Endian writing:",
| people won't have to wonder what "AD" means, and waste
| their and your time on asking (you will probably get this
| question a lot otherwise).
| wantlotsofcurry wrote:
| Radicle, Tangled, etc are the future of forges!
| HexDecOctBin wrote:
| What is the revenue model for Tangled? This is why ATProto
| stuff worries me, the AppView is expensive to host and no one
| has created a paid service yet to achieve sustainability.
| phoronixrly wrote:
| I don't see any revenue streams, just VC funding. Which
| raises all kinds of red flags.
| noelwelsh wrote:
| Can anyone describe how this differs from Tangled
| (https://tangled.org/)? Both seem very interesting, but I'm not
| deep enough into either to understand how they differ.
| lorenzleutgeb wrote:
| Tangled is built on top of the AT Protocol, and "mediates"
| between what they call "knots". Git servers. Their strength is
| to use AT Protocol to make communication across multiple Git
| servers work smoothly.
|
| Radicle is completely peer to peer. There are no such things as
| servers and clients, only nodes. However, there are quite a few
| nodes that then act as HTTP servers to offer convenient access
| via the browser.
| phoronixrly wrote:
| Also, Tangled is VC-funded. I cannot find information about
| Radicle, but considering the authorship is not advertised on
| their website, and that P2P is not easily monetizable, I
| would bet it is not VC-funded.
|
| All in all, seems like an awesome project and instantly more
| trustworthy and rugpull-resistant than Tangled.
| 0x3o3 wrote:
| yeah the Radicle protocol is fully owned and governed by a
| Swiss non-profit.
| phoronixrly wrote:
| As per https://radicle.xyz/history
|
| > The Radicle Foundation is established. A Swiss non-
| profit that oversees the development of the project.
|
| Thank you!
| creativeair2049 wrote:
| > instantly more trustworthy
|
| quite ironic, radicle seems to have raised 7m$ from
| "radworks", some sort of crypto foundation.
|
| that being said, why is it being _not monetizable_ a good
| thing? their website says radicle has been in development
| for 4 years already. without more money in the bank, how
| would they continue to build the thing?
| lorenzleutgeb wrote:
| Radicle is a free software project, not a company or
| commercial product. Many other open source projects are
| also not monetizable in the narrow sense, and still
| manage to attract enough contributors and funding to
| flourish. Sometimes these projects even get adopted so
| widespread that multiple companies build
| consortia/foundations to fund the development, even if
| there is no direct revenue stream from that.
|
| As long as someone is willing to fund the development of
| Radicle, the developers just will have a stronger
| incentive to work on it. Without any more funding, of
| course it will join the (very large) club of less well
| funded free software projects.
|
| If enough people join and contribute now, and then some
| companies make the switch, it might well be feasible to
| pay a small team to continue working on it, financed by
| donations.
|
| Just don't think about it as a commercial product, only
| because someone decided to use their money towards its
| development. If you don't like that it's not a company,
| then that's okay. I am just trying to give another
| perspective.
| 0x3o3 wrote:
| Radicle is architecturally local-first: you run your own node,
| sync repositories from a P2P gossip network, and then
| everything--browsing code, creating issues, reviewing patches--
| happens against your local data store. There's no round-trip to
| a server. Issues and patches are stored as signed Git objects
| (COBs) that replicate with the repo itself. The network is only
| involved when you choose to sync. This makes it extremely
| performant for day-to-day work and fully functional offline.
|
| Tangled to my understanding is federated in theory but
| centralized in practice. It relies on "knots" (servers that
| host Git repos) and a central AppView at tangled.sh that
| aggregates the network. Issues and social artifacts live on
| Personal Data Servers, not locally. While you can self-host a
| knot, the default experience routes through Tangled's managed
| infrastructure. The architecture is fundamentally client-
| server: your operations go over the network to wherever your
| data lives.
| fc417fc802 wrote:
| That implementation sounds really awesome but it raises a few
| questions for me (that I didn't immediately see when skimming
| the landing page although I realize answers might be in the
| docs somewhere).
|
| I found the answer to one of them (how automatic pinning
| works) which I'll paste here because others are likely to
| wonder as well. Related, I assume there's a way to block
| overly large files if you run a seed node?
|
| > They can vary in their seeding policies, from public seed
| nodes that openly seed all repositories to community seed
| nodes that selectively seed repositories from a group of
| trusted peers.
|
| Suppose I'm A and I collaborate with B, C, ... Z. If I file
| an issue locally and sync to C, am I able to see if and when
| that propagates through the network to everyone else? I guess
| what I'm wondering about is what the latency, reliability,
| and end user understandability are like when using this to
| collaborate in practice. Like if I file an issue on GitHub I
| know that it's globally visible immediately. How does that
| work here?
| lorenzleutgeb wrote:
| Currently, with Radicle still under active development, we
| already reach convergence times that are negligible for
| async collaboration (like working on code or issues).
| Working on a well-seeded repo, my changes sync to ~10 nodes
| within a tenth of a second and with ~80 nodes within 3
| seconds.
|
| This is obviously not fast enough for sync collaboration,
| like writing on a virtual whiteboard together, but that's
| also not what Radicle is designed for. Also, if you share
| larger files (e.g. you attach a screenshot to your issue)
| the above times might not be a good estimation anymore, but
| that's the exception for now.
|
| It's really strange to see that people assume that peer to
| peer networks somehow must be slow. In my experience, since
| everything runs locally, working with Radicle feels _way_
| more snappy than any web interface, which has lots of
| latency on every so-odd click.
|
| As the network scales, it'll of course take some care to
| keep the speed up, but that's known and there are a few
| models to take inspiration from.
| fc417fc802 wrote:
| It's not that I assume it must be slow, but rather that
| from experience being slow is a distinct possibility so I
| know to ask about it. But I also asked about reliability
| and visibility into the process. The latter is what I'm
| most curious about.
|
| I'm not meaning to suggest that I have a problem with any
| of it. It's just that when I see anything P2P that's
| mutable I start wondering about propagation of changes
| and ordering of events and how "eventual consistency"
| presents to end users in practice. Particularly in the
| face of a node unexpectedly falling off the network.
|
| I realize I could browse the docs but I figure it's
| better to ask here because others likely have similar
| questions and we're here to discuss the thing after all.
| lorenzleutgeb wrote:
| There's `rad sync status` which will show you (for a
| particular repository) which other nodes have echoed back
| to you that they have received and verified the most
| recent state of your namespace of that repository. So, if
| you expect some other node to have received your changes,
| you can use this command to verify that.
|
| When the user explicitly asks to sync, then by default
| the process will be considered to have completed
| successfully as soon as three other nodes have echoed
| that they have received your changes. This threshold is
| configurable. Further, one can define a list of nodes
| that they care particularly much about, in which case the
| process will only be considered to have completed
| successfully if all these nodes also signaled that they
| have received your changes.
|
| For anything deeper than that, you'd have to resort to
| logs. And if you connect your node to the other one your
| are interested, you can get a pretty good picture of
| what's going on.
|
| If one node "falls off" the network, then the above
| mechanisms will communicate that to you, or fail after a
| timeout.
|
| With Git repositories, humans establish order explicitly.
| They push commits which are a DAG. The collaboration
| around that (mostly discussions on issues, patches) is
| also stored in and synced by Git, but here, humans do not
| have to establish order explicitly. Rather, these things,
| in Radicle lingo called "Collaborative Objects" are
| CRDTs, so they will merge automatically. Nodes also
| opportunistically tag operations on these CRDTs with the
| latest operation they know, to help a bit by establishing
| an order where possible.
| fc417fc802 wrote:
| This sounds so much more appealing to me than github and
| co. Unfortunately I guess there's no multibillion dollar
| exit in the cards in this case.
|
| Has there been any thought about how this might interact
| with centralized-ish hosting? For example. Suppose a
| large project chose to use a radicle repo as its
| "blessed" point of coordination. Being a major project of
| course there's a mirror on (at minimum) github that
| points back to a web page (presumably the radicle app)
| for filing issues, collab, wiki, whatever.
|
| So a user that doesn't have any interest in learning
| about radicle wants to file an issue using the web app.
| When I glanced at the heartwood repo it seems to be read
| only with no indication of being able to log in (that's
| entirely unsurprising ofc). How much work / community
| welcome / etc is there likely to be for a project to
| offer a usable web front end, presumably leveraging a
| solution such as OIDC? Basically being able to "guest"
| users of centralized platforms in to the project so that
| they can collaborate with near zero overhead.
|
| As a motivating example consider outfits that want to
| self host a git forge but also want to offer centralized
| services to users. Communities such as KDE and SDL come
| to mind. Many of them have ended up migrating to github
| or gitlab over the years for various reasons but in an
| alternate reality it didn't have to be that way!
|
| I realize I'm effectively asking "do you have thoughts
| about implementing a partially federated model" but
| hopefully you can see the real world usecase that's
| motivating the (otherwise seemingly unreasonable)
| question.
| lorenzleutgeb wrote:
| It's a valid question, and in fact there's quite some
| interest in adding write features to the web app. The
| current version of Radicle was designed with one user per
| node in mind, to get things off the ground. The process
| of relaxing this is currently ongoing. First, to multiple
| users per node, which would make use-cases like the one
| you are sketching viable. What we'd like to avoid is to
| hand the key to the server, in such case, and instead
| generate an Ed25519 key in the browser, and sign there,
| with some web-compatible transport (HTTP? WebSocket?) in
| between. And that's just a bit more intricate than it
| sounds.
| eigenspace wrote:
| Anyone familiar with both projects that can give a comparison
| with the work happening on Forgejo (i.e. Forgefed protocal)?
| lorenzleutgeb wrote:
| Radicle is peer to peer. There are no "instances" or "servers"
| you interact with. The process that runs on your machine to
| synchronize changes across the network is the same as you would
| run on a server somewhere else. This is the core difference in
| network topology.
|
| What Forgejo are working on is to have their servers/instances
| communicate with each other via ActivityPub (IIRC). Think about
| it more like GitHub : Forgejo :: Twitter : Mastodon and
| possibly Filesharing : BitTorrent :: Software Development :
| Radicle.
|
| With Forgejo, every instance has its own database of user
| accounts, and controls who may log in or not (and so on). This
| is not the case with Radicle. Since there is no such authority,
| user accounts are self-certifying.
|
| For repositories, since there is no "standard location" like
| "the server", Radicle has developed a way to abstract from the
| user namespaces of the maintainers of a repo, to a canonical
| namespace. This is how references are lifted from individuals
| to a project. Not by having a copy on some particular server
| with access control. Of course, Radicle also has access
| control, but it is tied to the self-certifying identities, not
| to some server.
| woodruffw wrote:
| I'm heartened by efforts to build new social forges. At the
| absolute minimum, these kind of initiatives raise the background
| pressure on GitHub and GitLab to improve their products.
|
| From the FAQ:
|
| > For one, [git] has no way of verifying that the repository you
| downloaded after a git clone is the one you asked for, which
| means you need to clone from a trusted source (ie. a known
| server). This isn't compatible with peer-to-peer in any useful
| way.
|
| > Radicle solves this by assigning stable identities to
| repositories that can be verified locally, allowing repositories
| to be served by untrusted parties.
|
| What does this mean, in practice? At first glance this sounds
| like Radicle is turning a service trust problem into a PKI-shaped
| problem, which is more of a transmutation than a solution.
|
| Or more precisely: how do I know which stable repository
| identities to trust, and how is that trust distributed to parties
| in the network?
| iamnothere wrote:
| Trust would need to be established through other channels, or
| through careful code review, same as a repo by an unknown dev
| on GitHub. Once trust is established, you can look for other
| repos owned by the same DID if you want to see more by the same
| dev. If multiple versions of the same repo exist, and you want
| to find the "real" one, you may look for the one recommended by
| a trusted source or the one that is mentioned most elsewhere.
| Failing that you could look at development activity on the
| repo.
|
| Imagine a project with multiple repos on GitHub (not "forks"
| but someone actually uploaded it as a new repo). Similar
| problem. I've seen this before with some simple C libraries
| that haven't changed in years.
| endiangroup wrote:
| AD: I'll take a stab, but I am a new joiner!
|
| Each repository is governed by an identity document which is
| signed by a set of delegates, each delegate currently
| corresponds 1:1 to someones ssh-key. We are working to adjust
| this mechanism so you can have group identities, but its a hard
| problem and we're not the only ones working on it (note theres
| light at the end of this tunnel at this point).
|
| Seeing as you studied philosophy I'd argue what then do you
| mean by a solution? Aren't all solutions transmutations of
| prior 'things'? In the complex domain we have a word for it,
| exaptation - the radicle repurposing of something in a new
| context.
|
| That aside, how do you know which people to trust when you meet
| them? And how do you signal trust in those you've met? In
| Radicle holding stable cryptographic identities doesn't resolve
| the zero-to-some trust problem but it does resolve the some-to-
| more trust problem, I can continue trusting once I recognise
| and know an identity.
|
| So to answer "how is that trust distributed to parties in the
| network" - by stable cryptographic identities.
|
| To answer "how do I know which stable repository identities to
| trust" - by socialising, like you know how to trust people you
| meet in the world because you were introduced to them by
| someone else you trust.
| woodruffw wrote:
| Thanks for your detailed response.
|
| I guess what I mean is that trust is a hard problem, and a
| lot of solutions to trust involve transmuting a presupposed
| trust problem into a _different_ trust problem with a
| slightly different security model.
|
| For example: with a centralized service, I assume that a
| given identity is integral so long as the service is secure.
| I don't _need_ cryptographic identity for that centralized
| service, but that assumes I trust the service to be secure.
|
| With a distributed service, I need some way to ensure the
| integrity of identities. One way to do that is to TOFU, i.e.
| take a claimant identity on face value on first observation
| and then trust it going forwards. This works well for schemes
| like SSH, but it doesn't work super well for distributed user
| networks (because users like to lose their keys, and there's
| a _larger_ potential surface area for undetectable key
| substitution).
|
| Another solution is a "web of trust" architecture, where you
| take an initial trusted core and transitively extend trust
| outwards. The problems with this are (1) that trust isn't
| _actually_ transitive, and (2) it still presupposes a trusted
| core, which needs to be bootstrapped somehow.
|
| A third solution is a traditional PKI, where you have one or
| more pre-established identity "authorities" that sign for end
| user identities. This is the solution that HTTPS picks, and
| is arguably the most empirically proven of the decentralized
| identity schemes. But it's only as decentralized as the
| authorities themselves are, and there's a meaningful argument
| to be had about that (particularly in schemes that are
| smaller than the Web PKI).
|
| It sounds like Radicle is going with a mixture of (1) and
| (2), which is interesting and worth proving out. But my
| experience is that "someone's SSH key" is much less of a
| stable identity than we'd all like it to be, and schemes that
| involve delegating trust via unstable identities eventually
| run into architectural limitations that end users solve by
| just subverting the scheme itself (i.e. falling back to
| TOFU).
|
| > That aside, how do you know which people to trust when you
| meet them? And how do you signal trust in those you've met?
| In Radicle holding stable cryptographic identities doesn't
| resolve the zero-to-some trust problem but it does resolve
| the some-to-more trust problem, I can continue trusting once
| I recognise and know an identity.
|
| This is a good example both of how (1) social trust isn't
| easy to encode in cryptographic claims, and (2) how the
| transitivity of trust breaks down.
|
| In the real world, I trust my barber to cut my hair and my
| dentist to look at my teeth. But I _only_ trust them for
| their apposite roles, and my trust in my barber doesn 't
| necessarily mean anything to my friend who doesn't like my
| haircut.
| endiangroup wrote:
| AD: I have to clock off now, but I'll get back to this, I
| appreciate the well thought out response!
| jcranmer wrote:
| Your comments of trust reminded me of an analysis of the
| PGP strongly-connected component of the "web of trust,"
| back when keyservers were a bigger thing, and essentially
| found that, in practice, "web of trust" turned out to have
| a lot of key nodes that look very much like CAs in Web PKI.
|
| That is, for as much as a lot of cryptoenthusiasts want to
| talk about decentralizing trust and empowering users to
| have fine-grained trust decisions, in practice, most users
| really just want to offload all of the burden of ensuring
| someone is trustworthy on somebody else.
| noman-land wrote:
| Radicle is really cool. I've been running a node for months but
| havent pulled the trigger to use it as primary yet.
|
| We need better forges and they need to be p2p to survive. p2p is
| the only viable future for the web.
| endiangroup wrote:
| AD: Thank you for your contribution! I also run a permissive
| seed node, vote by participation!
| endiangroup wrote:
| AD: Whats holding you back from using it as your primary?
| hosh wrote:
| Not the original OP -- I had been thinking about this for
| years, though my interest is in resiliency rather than a
| sovereignty (though they overlap):
|
| - is there a mirror adapter to push to a non-radicle node,
| such as Github or say, sourcehut? (Mirroring nixpkgs, for
| example)
|
| - is there a mechanism to control syncs so it can be used on
| low-bandwidth, unreliable networks, or ad-hoc bluetooth
| networks?
|
| - is offline seeding possible or in the works?
|
| - language package managers often can reference a git or
| github. Would I be able to directly reference my local
| radicle node and have it manage (or perhaps even discover)
| the correct repos? (Or maybe this is a different problem and
| package repos themselves could be decentralized and
| sovereign)
|
| On that last point, I mean that the whole build chain and
| supply chain can be made sovereign: I see radicle is written
| in Rust, which means dependencies on Cargo, the Rust
| toolchain, and so forth.
| lorenzleutgeb wrote:
| > is there a mirror adapter to push to a non-radicle node,
| such as Github or say, sourcehut?
|
| You can just add a remote for another repository.
| git remote add github git@github.com:example/example.git
|
| You can also create remotes with multiple push URLs, so
| that with one `git push`, you push to all of them at once.
|
| Apart from that, it's possible to use e.g. systemd path
| units to run `git push` automatically whenever a repository
| gets updated by `radicle-node`.
|
| This works reasonably well. What else would the adapter
| have to do?
|
| > is there a mechanism to control syncs so it can be used
| on low-bandwidth, unreliable networks, or ad-hoc bluetooth
| networks?
|
| No. The data itself usually is quite small, as the common
| use case is to send commits. It's not optimized for
| unreliable networks or Bluetooth in any special way yet. It
| would certainly be useful.
|
| > is offline seeding possible or in the works?
|
| That's contradictory in my mind. What do you mean? Offline
| in the sense of "not connected to the internet"? That works
| just fine. Currently, you still have to connect your node
| to the existing network by connecting to another known node
| (via IP address or a DNS name that resolves locally). There
| are plans to integrate DNS-SD, also via mDNS.
|
| > language package managers often can reference a git or
| github. Would I be able to directly reference my local
| radicle node and have it manage (or perhaps even discover)
| the correct repos?
|
| For now, no. It's however reasonably simple to deploy a
| component called `radicle-httpd`, which will expose your
| repos via Git over HTTP if you like. Looks like this:
| https://seed.radicle.xyz/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git
|
| > (Or maybe this is a different problem and package repos
| themselves could be decentralized and sovereign)
|
| Yes. Consider things like
| https://www.tweag.io/blog/2020-12-16-trustix-announcement/
| hosh wrote:
| If the internet is down and you want to onboard someone
| with say, a usb thumbdrive.
|
| With the mirroring: does radicle have any kind of event
| hooks?
| lorenzleutgeb wrote:
| > If the internet is down and you want to onboard someone
| with say, a usb thumbdrive.
|
| All the data being synced is in a Git repo, which is in a
| directory on your filesystem we call "Radicle Storage".
| You can use `git bundle` or a plain `cp` to copy that
| directory over. You can also use plain Git to push. Note
| that for these use-cases there is no polished UX. You
| need to know what you are doing. The bigger issue will be
| to install Radicle.
|
| > With the mirroring: does radicle have any kind of event
| hooks?
|
| Yes. You can connect to `radicle-node` via a socket and
| subscribe to events. This is how Radicle CI, and in
| particular the Radicle CI Broker was implemented. You can
| implement your own event broker, it's just JSON over a
| socket.
|
| https://radicle-ci.liw.fi/radicle-ci-broker/ci-
| broker.html
| noman-land wrote:
| Honestly it's mostly lack of other users to interact with.
| It's my same problem with things like gitea. Someone needs an
| "account" to participate in your project.
|
| I'm also not sure how to sync issues and pull requests with
| Github.
|
| It's largely I haven't researched deeply enough yet.
| jrm4 wrote:
| Interesting. I've been critical on "decentralized" for other
| types of communication (e.g. ATProto/Bluesky) because it seems to
| forget that "forgetting is sometimes good."
|
| But this seems _excellent_ for code, a thing that (to the extent
| you can or should be) is mostly apolitical.
| endiangroup wrote:
| AD: We're looking ad introducing 'forgetting' as a feature,
| there may be a mutually beneficial way of signalling to
| permissive seeds when content is no longer relevant or stale or
| actively been flagged for removal.
| hackthemack wrote:
| I hang out with a small group of sysadmins who like to spin up
| the old internet stuff, like irc, gopher.
|
| And that got me to thinking about Usenet and how a ton of
| software (usually pirated) and images (usually pornography) were
| posted to it.
|
| And people often posted stupid stuff they said (usually because
| they were young and dare I say afflicted by a moment of dumb).
|
| I think one of the problems with p2p distributed systems is how
| do you handle "mistakes". Things you want deleted.
|
| What if someone accidentally posts their address and phone
| number?
|
| What if you post a communication system with encryption methods,
| but then the government passes a law that is criminal? Maybe in
| some regimes that puts you on a list for arrest? Look at what is
| happening with HAM radio operators and Belarus...
|
| https://www.niemanlab.org/reading/ham-radio-operators-in-bel...
|
| To me, none of this raises above the idea that distributed p2p
| content should not be used. It is just that it has some issues.
|
| Also, unrelated, but I think the plethora of "How does this
| compare to XYZ" type comments are not very helpful. It is too
| easy to write that kind of post, but much harder to answer.
| endiangroup wrote:
| AD: We're actively working on that issue right now, making the
| defaults safer. We're also discussing internally how to enable
| revocation of content at the network level. It won't be
| perfect, but neither is GitHub or the likes.
| fc417fc802 wrote:
| > We're also discussing internally how to enable revocation
| of content at the network level.
|
| Isn't that a solved issue? Or rather unsolvable. With
| ActivityPub there's just a deletion notification that's
| obfuscated so that you can't identify the item unless you
| already have a copy of it. What else can you do?
| lorenzleutgeb wrote:
| Right. Radicle nodes out of the standard distribution would
| be kind enough to delete. On the technological level you
| cannot do more (also not really less, funnily enough). But
| it would be possible to patch the code and remove deletion.
|
| Often times I just take the "information theory
| perspective": You fundamentally cannot make something "more
| private". Once it's out, it's out. You cannot "untell" a
| secret. That's just not how it works.
|
| But then other solutions also have this problem. Once I
| have `git fetch`ed from GitHub, or received that e-mail
| containing a patch on a mailing list, I have a copy on my
| filesystem. It's going to be pretty darn hard to remove it
| from there if I don't comply. Maybe you'd have to enforce
| some law.
|
| In that context, it seems that people were led to believe
| that "removal from the server(farm)" is the same as
| "removal from the universe", but that's just not true.
|
| Happy for any insight on how to approach this differently.
| hackthemack wrote:
| I am just glad some thought is being put into it. Thanks
| for the efforts.
|
| I keep thinking about people putting secrets up in
| github. You can not really get rid of something that is
| out there, like you said.
|
| But people do make a request to github to remove it. And
| if no one has put in the effort to copy it and republish
| it, it is not as "out there" as if it were still on
| github.
|
| Thinking on old BBS boards on the internet. Most people
| will use Internet Archive to search for old dead sites.
| If it is not on there, it is not as "out there" as if it
| were on the Internet Archive.
|
| I am thinking it is not quite as black as white as it
| seems. There is some kind of entropy effect.
|
| Thinking on pre-internet newspapers. If you posted
| something in a fan zine in the 70s, it might have faded
| from existence due to lost copies, or it might be in some
| collector's stockpile. It might even be scanned into the
| Internet Archive. Or not.
|
| No great solutions come to mind. But there does seem to
| be some "small" value in being able to say, delete this
| as it was a mistake.
|
| Maybe, also, more education, or a warning about "beware,
| be extra careful, this is going to be around for all to
| see for a long time, possibly forever".
| lorenzleutgeb wrote:
| > I keep thinking about people putting secrets up in
| github.
|
| You gave me an idea. For Radicle, we implemented a `git-
| remote-helper` (Git recognizes `rad://`-URIs and then
| wakes up the helper to handle the rest). This helper
| could well look at the blobs being pushed and detect
| secrets. Then error out and request a retry with
| `--force` if the user is sure.
|
| To implement something like this, we'd not want to
| reinvent the wheel, so we'd want to consume some
| description of patterns that we should look for. And
| obviously we're not going to ask GitHub or some web
| server.
|
| So, is there such library? In a format that is simple-ish
| to implement filtering for but also catches a good amount
| of secrets?
| fc417fc802 wrote:
| Yes, several well established secret scanners exist.
| Integrating one into radicle as a first class citizen is
| an awesome idea.
| axismundi wrote:
| There's https://github.com/gitleaks/gitleaks
|
| and https://github.com/mongodb/kingfisher
| phoronixrly wrote:
| You know, a centralized system is not immune to any of the
| issues you are listing here.
|
| Whether your mistakes can be deleted is up to the operator.
| They can even lead you to believe your content was deleted,
| while reporting it to the authorities.
|
| > What if you post a communication system with encryption
| methods, but then the government passes a law that is criminal
|
| Did you post it while it was legal to do so? Yes. Are _you_
| distributing it after it was deemed illegal? No. If you are in
| a country with a fair justice system, you wouldn 't have to
| worry. If you are in a country without one, they will find a
| much easier way to get you anyway.
| Dumbledumb wrote:
| In legal and public opinion distributions and authorship
| might not be looked at with such a technical lens, especially
| in a country trying to ban encrypted communications. A
| muddying between the two could easily be constructed
| intentionally, or unintentionally by ignorance of executive
| and judicial powers.
| phoronixrly wrote:
| As I mentioned, if you are inconvenient to your government
| in an authoritarian state, they will not bother with
| technicalities to get rid of you.
|
| Other people distributing code that you once authored will
| not stop by them getting rid of you.
| vlad-roundabout wrote:
| Can't you just download content from centralised services as
| well?
| pluralmonad wrote:
| This just seems like acknowledging the reality. If you publish
| something publicly, it's very possibly forever. Maybe a
| reasonable solution would be for a user client to delay
| publishing for a time (like an email client that lets you
| cancel/recall a sent email for a time).
| fc417fc802 wrote:
| A large proportion of historic usenet posts are archived and
| remain freely available today. Didn't google end up with one of
| the larger commercial archives? So that "stupid stuff" is still
| around unless it got deleted at the time (and wasn't archived
| first).
|
| New uploads to github are constantly being scanned by both
| benevolent and malicious actors for secrets that were
| inadvertently checked in. It's far too late by the time you
| notice and delete it.
|
| This P2P system doesn't appear to introduce any new problems
| that aren't already widespread.
| iamnothere wrote:
| Every time I read about an emulation or file sharing project
| kicked off of GitHub, I think: should have used Radicle.
|
| You can put your node behind Tor if you're worried about demand
| letters, by the way.
| fc417fc802 wrote:
| Is it straightforward to set up a seed node that's
| simultaneously available on multiple networks? For example tor,
| i2p, clearnet, and maybe even yggdrasil all at the same time. I
| ask because I recall (not git related) projects in the past
| that did not do well when configured in such a way.
| lorenzleutgeb wrote:
| Tor only (SOCKS) or Tor and clearnet is easy. Yggdrasil only
| is also easy (just restrict access to your tun). Yggdrasil
| and clearnet requires you to ensure that outgoing traffic
| takes the correct interface, this also applies if you want to
| combine with Tor. I don't know about I2P.
| ilaksh wrote:
| Can radicle seeds run over IPV6? Seems like since IPV6 doesn't
| have NAT it should be a big advantage for p2p and as it becomes
| more available the need for everyone to set up port forwarding or
| get a VPS to seed should go down.
|
| ISPs will try to block use of IPV6 for serving content, but
| eventually I think users will win because ultimately it should be
| a right to share information.
| lorenzleutgeb wrote:
| Yes. Radicle also makes it easy to run behind Tor, see
| https://radicle.xyz/guides/user#4-embracing-the-onion and there
| are people that use it via Yggdrasil, see https://yggdrasil-
| network.github.io/services.html#radicle-no...
| k__ wrote:
| Is Radworks/$RAD still a thing?
| lorenzleutgeb wrote:
| First, to make this clear: The Radicle network is not dependent
| on any blockchain technology, you can use it without holding
| any cryptocurrency/token. You do not need a wallet. You just
| need to generate an Ed25519 keypair for yourself.
|
| Radworks and RAD are still a thing, and the last vote
| (https://community.radworks.org/t/3698 and
| https://community.radworks.org/t/3703) was to fund Radworks App
| (https://radworks.org/app), Drips (https://www.drips.network/),
| Radicle Garden (https://radicle.garden/).
|
| Radicle development is funded by the Better Internet Foundation
| (https://betterinternet.foundation/), previously called
| "Radicle Foundation".
|
| RAD "tokenomics" are discussed here:
| https://community.radworks.org/t/3645/
| k__ wrote:
| Thanks!
|
| We cooperated with Radicle a few years ago, when they wer big
| in crypto. However, suddenly I saw posts here that were well
| received and noticed there wasn't any mention of $RAD on the
| radicle page anymore.
| acedTrex wrote:
| Damn the UI feels great, actually kind of eerie
| clot27 wrote:
| This seems good
| jrmg wrote:
| This certainly seems like a neat system. From the FAQ, two things
| I was most concerned about knowing:
|
| ----
|
| _How does Radicle deal with potential abuse, illegal content
| sharing etc. on the network?_
|
| Each node is free to choose which repositories to host (seed)
| using configured policies. Nodes can block specific repositories
| or peers exhibiting abusive behavior.
|
| _Is there a way to host private repositories on Radicle?_
|
| Yes, 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.
|
| https://radicle.xyz/faq
| creativeair2049 wrote:
| radicle is pretty neat, i'd be quite curious to read more about
| the state of CI and moderation (given the P2P nature).
| lorenzleutgeb wrote:
| For CI, please refer to https://radicle-ci.liw.fi/ and
| https://radicle.xyz/2025/07/23/using-radicle-ci-for-developm...
| 0x3o3 wrote:
| for the state of Radicle CI read this post from the maintainers
| https://blog.liw.fi/posts/2026/radicle-status-quo-01/
| iamnothere wrote:
| Re: moderation:
|
| Like BitTorrent, you choose which repos to mirror. If you're
| crazy or you watch your server like a hawk you could just
| choose to automatically mirror everything.
|
| Like BitTorrent there is no way to "moderate" what another node
| chooses to share.
|
| They are working on tools to help permissive nodes remove repos
| flagged for deletion, but the protocol itself does not prevent
| a node from ignoring this flag.
| jbstack wrote:
| Suggestion: improve the opening summary paragraph:
|
| " _Radicle is an open source, peer-to-peer code collaboration
| stack built on Git. Unlike centralized code hosting platforms,
| there is no single entity controlling the network. Repositories
| are replicated across peers in a decentralized manner, and users
| are in full control of their data and workflow._ "
|
| From this, I can't tell how it's any different to just plain
| self-hosted Git. A well written introduction should tell the
| reader immediately what the software actually does. If it's meant
| to be an alternative to something like gitea / forgejo then say
| that, with a brief summary of features that build on top of Git.
| endiangroup wrote:
| AD: Feel free to take a stab at an alternative, we're an open
| source project and we accept and welcome discussions but
| patches more so! What would read better in your opinion?
| bigbadfeline wrote:
| > What would read better in your opinion?
|
| You're asking someone else to describe what your project is
| doing?
|
| The lack of good description isn't unique, I've bee skipping
| more and more of those lately, but asking others to tell the
| developers what they've developed is new in my book.
| 533474 wrote:
| it reads fine to me
| the_other wrote:
| Reading the intro, I feel like I got a good hint about what
| this is. It sounded like "local first git for teams, without
| the hell of sharing patches via email".
|
| I don't know what gitea or forgejo are, so comparisons wouldn't
| help me.
| causalscience wrote:
| I can tell you. Forgejo is a git server (i.e. you can push to
| a remove that lives in a different machine) plus a web GUI
| that allows to list repos, list commits within a repo,
| navigate commits and files within a commit.
|
| The license is Free and Copyleft.
| zamalek wrote:
| You still have to run it on a server somewhere, which
| Nintendo can get shut down.
| overfeed wrote:
| Nintendo can't shutdown your git server if it's running
| on a Raspberry Pi in your pantry, or a NAS appliance in
| your home office/basement.
|
| As a matter of fact, Forgejo/Gitea are excellent choices
| for automatic mirroring of any Git repos you fear may be
| shutdown by DMCA shenanigans.
| saurik wrote:
| But if people can't find it, then they can't download the
| code or contribute to the project. And if people can find
| it, then there is no need to physically wrest your device
| out of your home: they'll just get your domain name taken
| away or your ISP to block the connections (at best, if
| not entirely shut you down).
| iamnothere wrote:
| That's why you host over Tor with an .onion domain.
| Immune to takedowns.
| lorenzleutgeb wrote:
| Right. Radicle would be one way to connect all these
| Raspberry Pis in many pantries together, and have them
| replicate each others repos. It also enables others to
| send patches, without first having to create an account
| on that Raspberry Pi in your pantry. And in case your
| Raspberry Pi is offline, others will just as happily
| serve your project, with cryptographic assurance that it
| wasn't modified.
|
| Don't get me wrong. Power to you and your Raspberry Pi!
| Radicle invites you to join a network of people that
| solve the same problem as you do, and pool resources.
| overfeed wrote:
| I wasn't shitting on Radicle - I think centralized Git is
| antithetical to the D in DVCS.
| yjftsjthsd-h wrote:
| In what way is git antithetical to being distributed?
| Github, sure, but git itself seems fine.
| dtj1123 wrote:
| The key word here is "centralized".
| zamalek wrote:
| They can get you arrested, and you wouldn't be their
| first.
| mistercheph wrote:
| Just like the MPAA is having people arrested for
| torrenting films?
|
| It doesn't scale well unless there's a centralized entity
| you can go after that controls distribution.
| badsectoracula wrote:
| Nintendo (or whoever) will shutdown whatever users visit
| to download the thing they want gone. From a skim through
| the user guide, Radicle seems to only handle the
| dev/backend side of things and Nintendo wouldn't care
| that much about it. After all there are already several
| git mirrors of Yuzu, what was lost was the official
| "download this" page and the centralized Github bits
| (issues, etc), though other projects could like handle
| this bit just fine either as addons (Forgejo) or natively
| (like the Fossil SCM).
| TeMPOraL wrote:
| The other day someone here coined JTPP - "Just the prompt,
| please", expressing preference for reading the prompt instead
| of the e-mail/article it produced. The reasons for that are
| rather obvious, but I think it applies to marketing copy in
| general.
|
| With that in mind, I wonder what the original idea behind
| this project was - the "prompt" that someone got in their
| mind, which got them excited enough to build this. Reading
| the "original prompt" might make it easier to figure the
| product out. Marketing copy is "how we can make what we have
| look more alluring to people". The "original prompt" is
| directly answering "what we actually aspired to build".
| mistercheph wrote:
| P2P Github
| fwip wrote:
| Unless something's changed since last I checked it out, it's
| git "on the blockchain." Including its own RAD-coin token.
|
| Edit: removed snarky line.
| lorenzleutgeb wrote:
| A lot has changed. But also you must've checked it quite some
| time ago. It's not on the blockchain anymore since the
| "heartwood" iteration, which was announced 2023-04-18. Please
| take some time to re-inform yourself, even just in this HN
| thread (search for "RAD ", the whitespace is significant).
| fwip wrote:
| Glad to hear it.
| Defelo wrote:
| I don't know about previous versions, but afaik since the
| release of the current heartwood implementation it is neither
| based on a blockchain nor does it include any "crypto" stuff.
| If it did, I probably wouldn't be using it.
| a-dub wrote:
| no, it's a distributed peer-to-peer alternative to something
| like github. it has all the features like a locally hosted
| forgejo/gitea/gitlab, but it also is built on a distributed and
| fault-tolerant peer-to-peer network for hosting public
| projects.
| dwa3592 wrote:
| I looked at the page and my understanding was that this is a
| decentralized github. Teams can collaborate without a company
| getting access to the code?
| immibis wrote:
| Would it make sense to build this on top of Freenet Locutus?
| rirze wrote:
| Been using radicle with jj for a little bit now-- just a toy
| project with only myself contributing and it's neat.
|
| Hopefully it will scale well and be ergonomic for collaboration.
| avaer wrote:
| This home page really needs a prominent gateway to the underlying
| gossip protocol so you can easily find every public repo on the
| network. Might be antithetical to the cause, though I argue it
| isn't. Maybe this already exists but I couldn't find it. And if
| this isn't technically possible, someone needs to solve that.
|
| The pitch is compelling; if the project home page shows that
| index, I can see a world where this takes the reigns from Github.
| Otherwise I don't see it.
| Defelo wrote:
| There is https://search.radicle.xyz/ if you want to search for
| public repos. But I don't know whether the home page links to
| it somewhere.
| untech wrote:
| I wonder how "permissive seeders" would be protected from folks
| pushing large binary files.
|
| Also, wouldn't storing everything about the repo make it very
| large? Even when cloning large git projects, it is from time to
| time necessary to make a "shallow clone" to avoid downloading
| hundreds of megabytes per repo. I imagine with all discussions it
| would be worse.
| mistercheph wrote:
| Awesome work! Just curious, has anyone worked on a tool for
| migrating github "collaborations"/ social artifacts to radicle,
| I'm confident this will be solved eventually as existing projects
| with treasured social artifacts on GH migrate, just curious about
| the current state.
| __MatrixMan__ wrote:
| I believe that one day, the bad guys are gonna level up such that
| centralized forges can't withstand corruption and we're gonna be
| real glad that people have been working on things like this all
| along.
| mxuribe wrote:
| Is it weird that one of the features that i look for in forge is
| the ability to star/bookmark a repo? But, since this is
| decentralized, makes sense that there is no central place to
| "house" said bookmark...So I'd either have to bookmark a repo
| using my browsers native, regular bookmarks....or in the future
| there could be feature to share, save/store said signal like the
| way ActivityPub, AT proto., etc.. handle it.
| lorenzleutgeb wrote:
| In the Radicle ecosystem, quite a few people like the idea to
| "seed" repos that they want to support. It means that you
| download the repo, and also announce to other nodes that you
| have it available to share. Thus, you are not only incrementing
| some counter in a central database, but you are actually
| contributing to the replication of the project on the network.
|
| The number of seeds then is a similar indicator as the number
| of stars.
|
| Of course, you can also just keep a list of repository IDs.
| mxuribe wrote:
| Kinda like legacy git cloning, but then of course sharing
| back not just with a signal (e.g. star, likes, etc.), but
| also actual contribution via replication of said source
| code...I love it!
| iamnothere wrote:
| As alternative git forges become more common, it might make
| sense to build a social bookmarking site for repos that can
| roll up repos from Radicle, Codeberg, Sourcehut, individual
| Gitlab instances, etc. Maybe it could include cross-platform
| search, alerting, and other tools.
|
| This might address some of the trust and discovery questions
| posed elsewhere in the discussion.
| mxuribe wrote:
| I sure hope something like said bookmarking sites come to
| pass! Though, if such functionality gets incorporated into
| existing activitypub stacks (and not as separate tools), that
| works too! :-)
| rurban wrote:
| > Data integrity is guaranteed by Git.
|
| > Synchronization is handled by Git.
|
| > Causal dependencies can be modeled as commit parent-child
| relationships.
|
| And there we have the problem. Git does not guarantee these
| things. Git is no CRDT. A proper replication protocol would, but
| git not. Git requires manual intervention to resolve coflicts.
| You end up with hourly conflicts, which need to be resolved
| manually, or not. Leading to inconsistencies all over when two
| people merge and resolve conflicts differently. Let not people
| merge, the system must handle this automatically. As in all
| online collaboration tools. Like Google Wave eg. If CRDT or as
| with databases PAXOS or single owner.
| lorenzleutgeb wrote:
| Where are you quoting from?
|
| Radicle implements so called "collaborative objects" (think:
| issues, patches, anything that multiple users collaborate on;
| except the source code itself) as CRDTs:
| https://radicle.xyz/guides/protocol#collaborative-objects
| rurban wrote:
| Next paragraph. The conflicts are not resolved. Or just use
| the non-solution as in git (or wikis). Leave it to human
| manpower.
| lorenzleutgeb wrote:
| For the source code in the repository, conflicts must be
| merged by users (or their tools, like `mergiraf`), just
| like with any other Git repo containing source code.
|
| What might confuse you is the mention that a collaborative
| object may opt in to ask the user to resolve a conflict.
| Well, in this case, strictly speaking, it's not a CRDT
| anymore of course. But none of the collaborative objects
| commonly used in Radicle use this escape hatch.
|
| It is clear that Git itself does not give you CRDTs, but
| Radicle implemented CRDTs on top of Git, which is entirely
| possible. This is also what's explained in the Protocol
| Guide. I don't understand what's the misunderstanding here,
| sorry.
| stavros wrote:
| Does anyone know if I can run this in Docker? I can't find
| anything either in the instructions or the internet at large, but
| also I don't know why it wouldn't run in Docker?
___________________________________________________________________
(page generated 2026-01-23 23:00 UTC)