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.
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.
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".
Changed "make a thing" to "describe a tool" and got a raft of text back that I couldn't be bothered to think about, because it's not my space. This jumped out though:
"## Existing things that almost do this (but don’t go far enough)
* Radicle – closest philosophically
[...]"
So it seems to me that you succinctly described Radicle - at least well enough for an LLM to recognize it.
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.
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).
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.
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).
The existing summary is great. It uses git in the first sentence. Meanwhile forjo's landing page seems to be activly avoiding the words git and source control leaving it a cryptic mess.
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.
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?
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.
Sometimes when you’re close to something it’s very hard to describe it because you’ve been looking at it from all angles for so long that when someone else approaches it from a different direction it’s hard to see what blind spots they might have. It’s not crazy to ask people for input and it’s not crazy to say “we’re open to patches if you just want to do it yourself”.
For me personally I was (and still am a bit) unclear on what being “based on git” means. Can I just rebase with abandon? Is there a concept of force push? Can I safely use lazy-git, tig, commit-patch, and other git utilities? Or is it more integrated and i have to use the rad cli to avoid corrupting the git repo? What about the issues? If I write some software and publish it with radicle, is there a way for plain git client to clone the repo without installing radicle (and without keeping a plain git mirror somewhere)?
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 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).
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?
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.
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.
Yeah, very much in the same vein. Someone should probably produce a pithy phrase for “if you think you have a web of trust, you probably have an informal, underspecified central authority.”
I agree trust is a hard problem when your coming from a problem<>solution framing. Trust is pretty abundant in our day-to-day lives if not a slightly backgrounded, for example; I trust my keyboard to type until the batteries run out or wear & tear gets the better of it, I trust my partner to hold care for me in mind when making decisions for me, I trust my dog to come back to me when I call for him... etc. In all those cases I've engaged on a epistemic and phenomenological journey mutually validating (at least) my experiences, my expectations and my actions. Because I remember my dog coming back to me in my previous experiences I trust and as such expect him to do so in the future. Because my keyboard continues to reflect my intent in writing this, I trust it is operating correctly. Because my partner has shown care for me a prior, I trust she will continue to do so.
I agree with your representations of centralised, TOFU and 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).
You're right 'someones ssh key' is unstable (not to detract from my my point but in the real world trust can be fickle and unstable too), however we can increase our certainty and are intending to. I'm interested in bring HSM's into Radicle, that swaps something you have on your computer to something you have on a physical device, but there are also further advancements like have been seen in the world of Keri where you can delegate identity to a log (KEL) which act as Autonomic Identifiers, these are self-sovereign, self-certifying sources of truth, we can have a set of keys and rules that govern the usage of them such that only 1 is valid at a time and if it is lost or compromised we can rotate safely and continue doing so.
> 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.
Agreed on 1.! I'd rather keep people good at what people do (continuously making and sharing trust judgements by engaging in the world) but enabling them to reflect that easily in their digital life. As for 2. I think it goes both ways depending on the context, it can breakdown but it can also compound amongst a plethora of other variations.
> 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.
I disagree, when talking conceptually of the role of barbers and trusting them at cutting my hair I agree, however when I go out into the real world and interact with my barber I trust them with more than just that! In fact I'd imagine many barbers would be offended at the idea they are ONLY trusted to cut hair in the barber shop. Try have that conversation with your barber next time you are there - if they aren't hurt by the idea of being reduced to a single role you might of found yourself a robot!
As for your trust in your barber meaning nothing to your friend who doesn't like your hair cut, I'd imagine your trust would of changed given the bad hair cut, but we could split this many ways, your friend might not like your hair cut but you like it - thats not much to do with the barber, your friend might not like your hair cut and you don't like your hair cut, not really a conducive situation for a recommendation, you might not like your hair cut and your friend might love it, now how loyal is your friend? Any attempt to enumerate out all of the variations is feeble, but hopefully the point comes through that theres a lot more going on than we can reduce.
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.
You can create a decentralized identifier for any repo with a properly formatted inception commit (a signed commit 0), that is the same for any git platform.
```zsh
eval "$(
cat <<'EOF'
zsh_git_inception() {
[ -d "$(pwd)/new_open_integrity_repo/.git" ] && echo " Repo already exists." && return 1
mkdir -p "$(pwd)/new_open_integrity_repo" && git -C "$(pwd)/new_open_integrity_repo" init > /dev/null
SIGNING_KEY="$(git config user.signingkey)"
GIT_AUTHOR_NAME="$(git config user.name)"; GIT_AUTHOR_EMAIL="$(git config user.email)"
GIT_COMMITTER_NAME="$(ssh-keygen -E sha256 -lf "$SIGNING_KEY" | awk '{print $2}')"
GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL"; GIT_AUTHOR_DATE="$(date -u +"%Y-%m-%dT%H:%M:%SZ")"; GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE"
GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
GIT_COMMITTER_NAME="$GIT_COMMITTER_NAME" GIT_COMMITTER_EMAIL="$GIT_COMMITTER_EMAIL" \
GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" GIT_COMMITTER_DATE="$GIT_COMMITTER_DATE" \
git -C "$(pwd)/new_open_integrity_repo" -c gpg.format=ssh -c user.signingkey="$SIGNING_KEY" \
commit --allow-empty --no-edit --gpg-sign \
-m "Initialize repository and establish a SHA-1 root of trust" \
-m "Signed-off-by: $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL>" \
-m "This key also certifies future commits' integrity and origin. Other keys can be authorized to add additional commits via the creation of a ./.repo/config/verification/allowed_commit_signers file. This file must initially be signed by this repo's inception key, granting these keys the authority to add future commits to this repo including the potential to remove the authority of this inception key for future commits. Once established, any changes to ./.repo/config/verification/allowed_commit_signers must be authorized by one of the previously approved signers."
[ $? -eq 0 ] && echo " Repo initialized!" || echo " Commit failed. Check Git settings."
}
zsh_git_inception
EOF
)"
```
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...
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.
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.
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.
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.
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).
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.
> 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?
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.
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".
> 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?
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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?
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
Not just the source is laden with conflicts. Also all other data. One rejects a PR, another merges it, the next still waits on a disapproval. This cannot work without CRDT. It's worse than source
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.
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.
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.
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!
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.
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! :-)
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.
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?
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.
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.
Unfortunately I won't have time for that; I just saw Radicle for the first time from this posting and wanted to drop-contribute what I think would reduce confusion for many people.
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!
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).
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?
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.
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.
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.
I had a few different issues getting the CI broker working the way I wanted to (don't even remember what the issues were, but it had to do with catching patches) so wired up my own way but simply polling via Git - using a thing I built a while back called goa (gitops agent) for another project.
The tricky part was getting the output from what ever do with the code, back into the Radicle patch. But it works.
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.
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.
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.
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.
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".
"make a thing that works like github but doesn't need github or email"
I wrote that as a joke but now that I'm reading it... even a terrible prompt might be useful.
Changed "make a thing" to "describe a tool" and got a raft of text back that I couldn't be bothered to think about, because it's not my space. This jumped out though:
"## Existing things that almost do this (but don’t go far enough)
* Radicle – closest philosophically [...]"
So it seems to me that you succinctly described Radicle - at least well enough for an LLM to recognize it.
P2P Github
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.
You still have to run it on a server somewhere, which Nintendo can get shut down.
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).
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.
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.
I wasn't shitting on Radicle - I think centralized Git is antithetical to the D in DVCS.
In what way is git antithetical to being distributed? Github, sure, but git itself seems fine.
The key word here is "centralized".
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).
That’s why you host over Tor with an .onion domain. Immune to takedowns.
Correct. Just ask the Silk Road guy…
They can get you arrested, and you wouldn't be their first.
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.
The existing summary is great. It uses git in the first sentence. Meanwhile forjo's landing page seems to be activly avoiding the words git and source control leaving it a cryptic mess.
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.
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?
it reads fine to me
> 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.
Sometimes when you’re close to something it’s very hard to describe it because you’ve been looking at it from all angles for so long that when someone else approaches it from a different direction it’s hard to see what blind spots they might have. It’s not crazy to ask people for input and it’s not crazy to say “we’re open to patches if you just want to do it yourself”.
For me personally I was (and still am a bit) unclear on what being “based on git” means. Can I just rebase with abandon? Is there a concept of force push? Can I safely use lazy-git, tig, commit-patch, and other git utilities? Or is it more integrated and i have to use the rad cli to avoid corrupting the git repo? What about the issues? If I write some software and publish it with radicle, is there a way for plain git client to clone the repo without installing radicle (and without keeping a plain git mirror somewhere)?
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?
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.
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 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).
Glad to hear it.
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?
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.
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.
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.
Yeah, very much in the same vein. Someone should probably produce a pithy phrase for “if you think you have a web of trust, you probably have an informal, underspecified central authority.”
AD: I have to clock off now, but I'll get back to this, I appreciate the well thought out response!
AD: Thanks for engaging in a constructive way!
I agree trust is a hard problem when your coming from a problem<>solution framing. Trust is pretty abundant in our day-to-day lives if not a slightly backgrounded, for example; I trust my keyboard to type until the batteries run out or wear & tear gets the better of it, I trust my partner to hold care for me in mind when making decisions for me, I trust my dog to come back to me when I call for him... etc. In all those cases I've engaged on a epistemic and phenomenological journey mutually validating (at least) my experiences, my expectations and my actions. Because I remember my dog coming back to me in my previous experiences I trust and as such expect him to do so in the future. Because my keyboard continues to reflect my intent in writing this, I trust it is operating correctly. Because my partner has shown care for me a prior, I trust she will continue to do so.
I agree with your representations of centralised, TOFU and 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).
You're right 'someones ssh key' is unstable (not to detract from my my point but in the real world trust can be fickle and unstable too), however we can increase our certainty and are intending to. I'm interested in bring HSM's into Radicle, that swaps something you have on your computer to something you have on a physical device, but there are also further advancements like have been seen in the world of Keri where you can delegate identity to a log (KEL) which act as Autonomic Identifiers, these are self-sovereign, self-certifying sources of truth, we can have a set of keys and rules that govern the usage of them such that only 1 is valid at a time and if it is lost or compromised we can rotate safely and continue doing so.
> 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.
Agreed on 1.! I'd rather keep people good at what people do (continuously making and sharing trust judgements by engaging in the world) but enabling them to reflect that easily in their digital life. As for 2. I think it goes both ways depending on the context, it can breakdown but it can also compound amongst a plethora of other variations.
> 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.
I disagree, when talking conceptually of the role of barbers and trusting them at cutting my hair I agree, however when I go out into the real world and interact with my barber I trust them with more than just that! In fact I'd imagine many barbers would be offended at the idea they are ONLY trusted to cut hair in the barber shop. Try have that conversation with your barber next time you are there - if they aren't hurt by the idea of being reduced to a single role you might of found yourself a robot!
As for your trust in your barber meaning nothing to your friend who doesn't like your hair cut, I'd imagine your trust would of changed given the bad hair cut, but we could split this many ways, your friend might not like your hair cut but you like it - thats not much to do with the barber, your friend might not like your hair cut and you don't like your hair cut, not really a conducive situation for a recommendation, you might not like your hair cut and your friend might love it, now how loyal is your friend? Any attempt to enumerate out all of the variations is feeble, but hopefully the point comes through that theres a lot more going on than we can reduce.
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.
You can create a decentralized identifier for any repo with a properly formatted inception commit (a signed commit 0), that is the same for any git platform.
See https://github.com/OpenIntegrityProject/core/blob/main/docs/...
```zsh eval "$( cat <<'EOF' zsh_git_inception() { [ -d "$(pwd)/new_open_integrity_repo/.git" ] && echo " Repo already exists." && return 1 mkdir -p "$(pwd)/new_open_integrity_repo" && git -C "$(pwd)/new_open_integrity_repo" init > /dev/null SIGNING_KEY="$(git config user.signingkey)" GIT_AUTHOR_NAME="$(git config user.name)"; GIT_AUTHOR_EMAIL="$(git config user.email)" GIT_COMMITTER_NAME="$(ssh-keygen -E sha256 -lf "$SIGNING_KEY" | awk '{print $2}')" GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL"; GIT_AUTHOR_DATE="$(date -u +"%Y-%m-%dT%H:%M:%SZ")"; GIT_COMMITTER_DATE="$GIT_AUTHOR_DATE" GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \ GIT_COMMITTER_NAME="$GIT_COMMITTER_NAME" GIT_COMMITTER_EMAIL="$GIT_COMMITTER_EMAIL" \ GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" GIT_COMMITTER_DATE="$GIT_COMMITTER_DATE" \ git -C "$(pwd)/new_open_integrity_repo" -c gpg.format=ssh -c user.signingkey="$SIGNING_KEY" \ commit --allow-empty --no-edit --gpg-sign \ -m "Initialize repository and establish a SHA-1 root of trust" \ -m "Signed-off-by: $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL>" \ -m "This key also certifies future commits' integrity and origin. Other keys can be authorized to add additional commits via the creation of a ./.repo/config/verification/allowed_commit_signers file. This file must initially be signed by this repo's inception key, granting these keys the authority to add future commits to this repo including the potential to remove the authority of this inception key for future commits. Once established, any changes to ./.repo/config/verification/allowed_commit_signers must be authorized by one of the previously approved signers." [ $? -eq 0 ] && echo " Repo initialized!" || echo " Commit failed. Check Git settings." } zsh_git_inception EOF )" ```
It's a misunderstanding of the git data model to think there is a singular first commit. It's a DAG with potentially multiple roots.
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.
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.
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.
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.
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.
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).
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.
> 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?
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.
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".
> 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?
There's https://github.com/gitleaks/gitleaks
and https://github.com/mongodb/kingfisher
As Radicle is written in Rust, I was hoping for a way to use Kingfisher as a library, but did not find one. So I filed https://github.com/mongodb/kingfisher/issues/189
Of course, it'd always be possible to invoke some binary. But I am still curious about a library.
The simplest way to use kingfisher is global pre-commit hook. Works with any git repo. rad could suggest to install this as a part of privacy hygiene.
Yes, several well established secret scanners exist. Integrating one into radicle as a first class citizen is an awesome idea.
Can't you just download content from centralised services as well?
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
yeah the Radicle protocol is fully owned and governed by a Swiss non-profit.
As per https://radicle.xyz/history
> The Radicle Foundation is established. A Swiss non-profit that oversees the development of the project.
Thank you!
> 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?
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.
Source for it being VC funded?
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
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.
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.
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.
AD: Thank you for your contribution! I also run a permissive seed node, vote by participation!
AD: Whats holding you back from using it as your primary?
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.
> 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.
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/
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?
> 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
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.
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.
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.
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.
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.
Anyone familiar with both projects that can give a comparison with the work happening on Forgejo (i.e. Forgefed protocal)?
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.
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.
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.
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.
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...
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.
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.
> 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.
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
Next paragraph. The conflicts are not resolved. Or just use the non-solution as in git (or wikis). Leave it to human manpower.
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.
Not just the source is laden with conflicts. Also all other data. One rejects a PR, another merges it, the next still waits on a disapproval. This cannot work without CRDT. It's worse than source
Damn the UI feels great, actually kind of eerie
Radicle, Tangled, etc are the future of forges!
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.
I don't see any revenue streams, just VC funding. Which raises all kinds of red flags.
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.
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.
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!
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.
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! :-)
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.
Here's a question: does Radicle support a http API, or is there a Radicle-to-git server bridge?
I know it sounds crazy, against the whole purpose. But all I want is to patch it into ArgoCD in my homelab k8s cluster...
Yes, there is: https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z4V1sjrXq... This is the full web app powering https://app.radicle.xyz/ including radicle-httpd which simply serves an http api used by the radicle-explorer frontend and which can also be used as a (readonly) git remote.
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?
AD: Newly joined protocol dev here, feel free to ask questions!
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?
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.
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:
(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_patchset...
https://kernelnewbies.org/PatchPhilosophy#Patches_are_git_co...
AD: Those are fair points, feel free to jump on our [zulip](https://radicle.zulipchat.com/#recent) and start a discussion there!
Unfortunately I won't have time for that; I just saw Radicle for the first time from this posting and wanted to drop-contribute what I think would reduce confusion for many people.
You'll have to take it from here :-)
This sounds really, really cool. How does reviewing such patch-PR's work?
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!
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).
Your initials form a word used as a disclaimer often. And shared HN accounts are not common.
Thanks for clarifying.
Just for reference, usually folks in this situation use postfix initials rather than prefix (like how blockquotes are cited).
- J.S.
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?
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.
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.
radicle is pretty neat, i'd be quite curious to read more about the state of CI and moderation (given the P2P nature).
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.
I had a few different issues getting the CI broker working the way I wanted to (don't even remember what the issues were, but it had to do with catching patches) so wired up my own way but simply polling via Git - using a thing I built a while back called goa (gitops agent) for another project.
The tricky part was getting the output from what ever do with the code, back into the Radicle patch. But it works.
https://revolveteam.com/blog/goa-radicle-ci/
There are some caveats - mostly security related - given this is potentially executing commands on a host node.
For CI, please refer to https://radicle-ci.liw.fi/ and https://radicle.xyz/2025/07/23/using-radicle-ci-for-developm...
for the state of Radicle CI read this post from the maintainers https://blog.liw.fi/posts/2026/radicle-status-quo-01/
I wish it would support more VCSs.
Is Radworks/$RAD still a thing?
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/
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.
This seems good
[dead]
Would it make sense to build this on top of Freenet Locutus?