"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.
I don't know what gitea or forgejo are, so comparisons wouldn't help me.
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".
The license is Free and Copyleft.
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.
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.
It doesn't scale well unless there's a centralized entity you can go after that controls distribution.
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.
Edit: removed snarky line.
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?
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.
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.
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.
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.
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.
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.
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?
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.
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".
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?
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.
Other people distributing code that you once authored will not stop by them getting rid of you.
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.
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?
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.
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.
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.
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.
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.
All in all, seems like an awesome project and instantly more trustworthy and rugpull-resistant than Tangled.
> The Radicle Foundation is established. A Swiss non-profit that oversees the development of the project.
Thank you!
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?
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.
——
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.
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.
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.
We need better forges and they need to be p2p to survive. p2p is the only viable future for the web.
- 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.
You can just add a remote for another repository.
git remote add github git@github.com:example/example.git
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/
With the mirroring: does radicle have any kind of event hooks?
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.
I'm also not sure how to sync issues and pull requests with Github.
It's largely I haven't researched deeply enough yet.
> 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.
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
You can put your node behind Tor if you’re worried about demand letters, by the way.