> Radicle repositories, which can be either public or private, can accommodate diverse content including source code, documentation, and arbitrary data sets.
If this is, basically, a peer-to-peer file sharing application, what part of the protocol handles dealing with abuse?
Otherwise, how is this different from the previous generation of file sharing applications (BitTorrent, winny, etc) where people just share arbitrary copyrighted content like movies, songs, software, etc?
I feel like a few bad actors will ruin this?
Can you partition your “personal” network somehow, so you can use it with absolute confidence your not participating in anything illegal?
One of the key ideas is that each user chooses what repositories they host via pretty fine-grained policies. This means you can easily block content you're not interested in seeding, or simply configure your node to only host content you explicitly allow.
You can also choose which public nodes to connect to if you'd rather not connect to random nodes on the network; though I don't expect most users to go this route, as you are more likely to miss content you're interested in.
Though Git (and thus Radicle) can replicate arbitrary content, it's not particularly good with large binary files (movies, albums etc.), so I expect that type of content to still be shared on BitTorrent, even if Radicle were to be popular.
For example, if I use Radicle to version a machine learning project, can I use a Magnet link for multi-GB model files?
For example, allow users to be able to subscribe to specific repos or specific topics or specific people etc
(P.S. I am working at Radicle)
how will this not devolve into freeNet fiasco when popular repos start to go wild on content?
edit: i see from the finance thread you will likely take on maven/npm/etc with crowd hosting+funding so I'm now more curious how cheap it will be for bad actors to push intentional malicious content, since now it's mostly about cost of having consensus over the mirrors
> Radworks is a community dedicated to cultivating internet freedom.
They do not shy away from cryptocurrency technology, though AFAICS that is not directly applied to the Radicle project. Another project of Radworks is Drips [1], to help fund open source.
I'm all for a distributed self-hosting solution, so Radicle is definitely hitting the mark here, however:
> Linux or Unix based operating system.
For the kind of project I have to assist with, this would be a deal-breaker. Since the code seems to be in Rust: do you intend to make it available to MS Windows? (I took it for granted that Mac OS is included in the Unix family, right?)
If not straight-up support for MS Windows, then maybe an MSYS2 port?
----
To give some background: I'm not in charge of decisions like service vendor selection, and we are talking about a quasi-government organization with substantial open-source code base that is currently hosted on Github. I.e. sometimes I might have a chance to pitch a particular idea, but it's not up to me if the idea is accepted. They are quite motivated to make their work as resilient to private vendor policies as possible as well as try to "do good" in other ways (i.e. sustainability, breadth of the outreach etc. -- a typical European gov. org :) So, Github is... obviously in conflict with such policies.
While there are other gov. agencies tasked with archiving or networking support, they seem to be woefully incompetent and / or outdated, as well as often falling for the vendor-laid traps (eg. the archiving service went all-in after DataBricks not even realizing it's a commercial closed-source product). So, I wouldn't have high hopes for the org. to be able to leverage a self-hosted solution. That's why a distributed solution looks great.
However, they wouldn't be able to use a tool that doesn't work on major popular PC systems.
Radicle does work on macOS as well.
The product is set to launch this month, so we're just starting to onboard users, but many people in the community are already using it, and we've been using it internally for about a year.
An idea doesn't take off -- totally normal, but how on earth can you fund Radicle for such a long time with no users? You can even throw it away and rewrite it! What's the source of funding for Radicle ?
Asking because you seem to be best at getting the idea funded, not really actualizing it.
Open-source projects obviously need to pay the bills, but if you're not clear on how you are achieving this or hoping to achieve this then there's really zero trust in using this.
also, i'm curious, what kind of adoption were you anticipating (some time ago and now) and did the result align with it?
[0]: https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3gqcJUoA...
A workflow of this sort doesn't need nixpkgs at all, but it does require that the nix flake input handler knows how to fetch from radicle repos. I'll try it a bit later today, but I'm guessing that this will require a change to nix before it works.
No need for crypto/digital currency whatsoever.
These guys picked "distributed source code repositories, with a client idiosyncratically written in Rust and idiosyncratically built with a cryptocurrency idea." Why?
I agree it's intellectually stimulating. But besides that, is there a reason they are particularly passionate about distributed source code repositories?
Thing is, building UIs to clone GitHub is a huge grind. It's not anything anyone asked for, and there aren't any innovations there. Then building all this infrastructure and documentation is also a grind. Then this is a grind, and that is a grind, and you add up all this stuff that is kind of a grind. So you have this original... radical of an interesting idea, that is intellectually stimulating, but then you have to do all this work that is a grind, and it's like, why?
So in my experience there's someone back there who has a certain manic energy, an ability to focus on doing this grind. There's no audience, so there are no bug reports, so it can sort of be all work channeled into product development just for the psychic satisfaction of pumping out GitHub UI clones, documentation, install scripts, infrastructure, documenting and evangelizing a "protocol" etc. I mean that's 90% of the work right? So why not harness that manic energy elsewhere?
I'm not making a judgement, but I'm trying to figure out where the sincere excitement lies. Like if you are willing to put up with this grind, you can also contribute 1 feature to Git, which already exists, and that could get 1,000,000x the adoption and be 1,000,000x more impactful. I don't know. So it's not about that. It's not about growth growth growth, or whatever.
If you have the manic energy to do any mundane task, like if the authors don't really care about which grind it is or how much it is, why not channel it into something else that maybe they are more passionate about? Like who is sincerely passionate about distributed source control, but hasn't already found their proverbial tribe in the many, many places where you can be excited about something like that?
I bring up "video games" because it's stereotypically the thing the quiet kid who suddenly becomes very wealthy doing something meaningless (sorry, that's true about distributed source control) and then now, he has the money to do whatever he wants, so he funds a Diablo clone or whatever. It's only a half joke. But it's like, why? Why this?
Of course one answer is that, for many people, they see $12m as Finally My Payday. They'll say or do anything to make that happen. If it happens to be that their lane is Authoring Idiosyncratic Computer Science Research Projects, that's what will be related to getting the payday. If that happens to be their lane because they look like a guy who plays Diablo and drinks energy drinks and is good at math and has manic energy to program cryptocurrencies... okay. That could be true.
This is just a colorful comment. But I think there's something more sincere there, and that's what I'm asking for, and unfortunately there is a way to tell in writing if someone is or is not sincere, versus just trying to keep their payday, and that's the risk with exposing yourself to the community, and that's fine.
I attended the workshop at Protocol Berg 2023 and think they built something really powerful and novel.
Perhaps the most exciting aspect is that even the collaborative aspect of the protocol is local-first which means you can submit patches and issues without internet and that your team isn't on HN every time GitHub is having problems.
What's missing in git is code issues, wikis, discussions, github pages and most importantly, a developer profile network.
We need a way to embed project metadata into .git itself, so source code commits don't mess up with wikis and issues. Perhaps some independent refs like git notes?
For one, it 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 p2p in any useful way.
Radicle solves this by assigning stable identities[0] to repositories that can be verified locally, allowing repositories to be served by untrusted parties.
[0]: https://docs.radicle.xyz/guides/protocol#trust-through-self-...
Respectfully disagree here. A repository is a(or multiple) chain(s) of commits, if each commit is signed, you know exactly that the clone you got is the one you asked for. You're right that nobody exposes a UI around this feature, but the capability is there if anyone would have any workflows that require to pull from random repositories instead of well established/known ones.
Another thing is knowing if the commit history has been tampered with without knowing the hash.
The reason for needing to not know the hash is for cases like tornado cash. The site and repo was taken down. There's a bunch of people sharing a codebase with differing hashes, you have no idea which is real or altered.
This is also important for cases where the domain is hacked.
> This is also important for cases where the domain is hacked.
I think at some point you need to know some sort of root-of-trust to kick off the trusting process. I believe in this case, you would trust a certain DID or set of DIDs (i.e. a Tornado Cash developer's public key). You can clone their version of the project and the history of the project MUST be signed by their private key for it to be legitimate.
To clarify, in Radicle, a peer's set of references are always signed by their key and this data is advertised so that you can always verify, using their public key, that this data is indeed what this peer has/had in their Git history. If this ever diverges then any fetching from that peer is rejected.
Domains with DNSSEC are an interesting solution. PGP public keys are distributable via DNS records.
https://www.pgp.guide/pgp_dns/
https://weberblog.net/pgp-key-distribution-via-dnssec-openpg...
> Is Hardened SHA-1 vulnerable?
> No, SHA-1 hardened with counter-cryptanalysis (see ‘how do I detect the attack’) will detect cryptanalytic collision attacks. In that case it adjusts the SHA-1 computation to result in a safe hash. This means that it will compute the regular SHA-1 hash for files without a collision attack, but produce a special hash for files with a collision attack, where both files will have a different unpredictable hash.
Radicle adds issue tracking and pull requests. Probably some of those other features as well.
On mobile there are buttons on the bottom of the screen in the op link, click those and you get to the issue tracking tab and the pull request tabs etc
https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3trNYnLW...
You would have to either add the features to git itself, or at least add to git the knowledge of and allowance for extra features like that.
But not just toss non-git data in .git/ simply because the dir happens to exist.
Fossil (https://fossil-scm.org) embeds issues, wiki etc. into project repository.
What has the world come to where that is the most important part?
--
I think gerrit used to store code reviews in git.
There is nothing stopping me from creating the accounts IggleSniggle or Iggle5n1ggle on github.
If you simply host Git on IPFS you have it properly decentralized without the limits of HTTP. IPNS (DNS of IPFS), which you need to point people to the latest version of your repository, however wasn't working all that reliably last time I tried.
IIUC with Radicle you can just request the repository by signature and get the latest released version from the network without needing to track down a source yourself. A trusted publisher (probably the original author/maintainer) can continue to publish commits without a centralization point that can be shut down (like the recent Yuzu case).
Also radicle does want to tackle the issues / prs and other elements you mentioned as well.
And presumably the person hosting it will make sure that the computer hosting it is often on, for instance ISP routers and TV boxes are a good way to popularize it, since they often come with NAS capabilities :
https://en.wikipedia.org/wiki/Freebox
(Notably, it also supports torrents and creating timed links to share files via FTP.)
- finding what the domain name is ? - resolving the DNS to an IP address ?
Radicle solves both problems in theory, but more the latter than the former right now:
- there is some basic functionality to search for projects hosted on Radicle, to find the right repo id (I expect this area will see a lot more activity and improvements in the near future), - given a repo id, actually getting the code onto your laptop. This is where the p2p network comes in, so that the person hosting it doesn't always need to keep their computer/router/tv box on, etc.
i know i've encountered something like this once in a notable repo. thought it was graphics related, like mesa or something, but looks like they're using GitLab.
> It’s important to only publish repositories you own or are a maintainer of, and to communicate with the other maintainers so that they don’t initialize redundant repository identities.
Based on my experience with people taking my code and shoving it onto GitHub--as well as separately in my demoralizing general experience of putting random little "please for the love of all that is holy don't do X as it will cause problems for other users" notices in the documentation or even as interstitial UI (!!) of my products and watching everyone immediately do exactly that thing as no one reads or thinks (or even cares)--a large number of people aren't going to honor this request in the documentation... and, frankly a large number of people aren't even going to see this in the first place as the home page tells you how to push code but you only find this "important" request in the "user guide" that people definitely do not bother to read.
It thereby seems quite concerning that, apparently?!, this system is designed in a way where doing what feels like a very reasonable thing to do--just pushing whatever open source code you are working on, based on the instructions on the home page--is going to interact with something about this protocol and how things are stored that something important enough to have this separated boxed "important" statement in the documentation is going to get cluttered and maybe even confusing over time :(.
On GitHub, you also can look at the stars to give you extra confidence, and on Radicle the equivalent is the seed count for a given repository.
Kind of off topic, but you shouldn't get annoyed at people for ignoring your notices and not reading the docs. It's an extremely logical thing to do. Think about it - how many notices do you see in a typical day of computing? Probably dozens. How many tools to you use? Also dozens. Now imagine how long it would take if you read all of those notices, and exhaustively read the documentation for every tool. Too fucking long!
It's much better to use heuristics and not read. For example if you close a document and you've made unsaved changes to it, you know the dialog is going to be "Do you want to discard it?". There's no point reading it.
This is a good thing!!
So the conclusion is that you should design your software with the knowledge that people behave this way. It is usually possible to do so. If you give a concrete example I can probably suggest a better solution than "asking and hoping they read it".
Which, though, leads me to something I will say in response to your reframing: while I do believe that one must build systems with the understanding that people will not read any of the documentation, we should still judge people for the behavior. I am pro commingled recycling, and yet I also believe that people who don't even try to read the signs on top of a series of trash bins are shirking a duty they have to not be a jerk, the same way we should be angry at people for not knowing local laws even if we put them on giant signs on the street as they'd rather just be lazy.
git pull github master
git push rad masterMigrating GitHub Pull Requests (PRs) to Radicle Patches is somewhat more involved, but that should still be possible (even if it involves some loss of information along the way, due to potential schema mismatches) ...
[1] - https://github.com/cytechmobile/radicle-github-migrate
The main value capture at Github is issue tracking, PR reviews and discussion. Maybe not today, but is there an automated way to migrate these over in the future?
site:app.radicle.xyz
Tools for integrating CI support with this would also be nice to see. Ultimately a loop with
while true; do wait_repo_update; git pull && ./run_ci.sh; done
And then finally artifact storage. But maybe Radicle doesn't need to solve everything, in particular as a distributed network for sharing large binaries is going to get some undesirable uses pretty fast..
I realize I'm just some rando on the Internet, but I'm begging you please don't introduce Yet Another CI Job Specification ™
I'm sure you have your favorites, or maybe you hate them all equally and can just have a dartboard but (leaving aside the obvious xkcd joke) unless you're going to then publish a JSON Schema and/or VSCode and/or IJ plugin to edit whatever mysterious new thing you devise, it's going to be yet another thing where learning it only helps the learner with the Radicle ecosystem, and cannot leverage the existing knowledge
It doesn't even have to be yaml or json; there are quite a few projects which take the old(?) Jenkinsfile approach of having an actual programming language, some of them are even statically typed
I also do recognize the risk to your project of trying to fold in "someone else's" specification, but surely your innovation tokens are better spent on marketing and scm innovations, and not "how hard can it be" to cook a fresh CI job spec
I likely would have already written a much shorter comment to this effect, but having spent the past day slamming my face against the tire fire of AWS CodeBuild, the pain is very fresh from having to endure them thinking they're some awesome jokers who are going to revolutionize the CI space
It’s interesting, because it’s like the problem is partly that most of the CI offerings out there are at least a little bit gross, but also the vast number of mediocre CI offerings is a factor too.
It feels like it’d be easy to convince yourself that what you’ve built is better than everything that exists already, and hey, maybe it is! But personally I wonder if we really need is a step-change here, not an incremental improvement—something that really does make build and deploy easier, and changes how we all think about it too.
So a peer to peer system is one where all participants are "equally privileged in the network". This usually means they all run the same software as well.
I guess im mostly just wondering what are the properties you are trying to accomplish. Like there is talk of publicly seeding repositories that are self-certifying, but also using noise protocol for encryption, so what is the security model? Who are you trying to keep stuff secret from? It is all very confusing what the project actually aims to do.
Mostly all i'm saying is the project could use a paragraph that explains what the concrete goals of the project are. Without buzzwords.
But yes, we're not officially launched yet and the website is going through a rewrite to offer more clarity, thanks for the feedback.
Re: seed nodes: they are running the same software and work the same way as regular nodes, the only difference is how they're deployed (with a public IP address vs. behind a NAT). But yes, a little bit of asymmetry is needed because of NATs/IPv4.
Re: properties: mainly we need to provide encryption and self-certification to enable a similar user experience as GitHub/GitLab/etc. on a an untrusted peer-to-peer network. Additionally though, Radicle offers a level of censorship resitance and disruption tolerance that GitHub cannot offer.
>
>The easiest way to install Radicle is by firing up your terminal and running the following command:
>
>$ curl -sSf https://radicle.xyz/install | sh
Ah.. my high hopes were immediately dashed by the trash that is curl-bash. What a great signal for thoughtless development, if this project catches on I can't wait to watch the security train wreck unfold. Maybe someday we'll get an "Open-Source, Peer-to-Peer, GitHub Alternative" that doesn't start with the worst possible way to install something.
Risks inherent to pipe installers are well understood by many. Using your logic, we should abandon Homebrew [1] (>38k stars on GitHub), PiHole [2] (>46k stars on GitHub), Chef [3], RVM [4], and countless other open source projects that use one-step automated installers (by piping to bash).
A more reasonable response would be to coordinate with the developers to update the docs to provide alternative installation methods (or better detail risks), rather than throwing the baby out with the bathwater.
[1] https://brew.sh/
[2] https://github.com/pi-hole/pi-hole
[3] https://docs.chef.io/chef_install_script/#run-the-install-sc...
The script is safe regarding interrupted transfer, unless you happen to have a dangerous commands in your system matching ^(t(e(m(p(d(ir?)?)?)?)?|a(r(g(et?)?)?)?)?|i(n(_(p(a(th?)?)?)?|fo?)?)?|s(u(c(c(e(s?s)?)?)?)?)?|f(a(t(al?)?)?)?|m(a(in?)?)?|w(a(rn?)?)?|u(rl?)?).
And after that's been handled, well, what's the difference to just providing the script but not the command to invoke it? Surely if one wants to review it, downloading the script to be run separately is quite straightforward. (Though I there was a method for detecting piped scripts versus downloaded ones, but I don't think it works for such small scripts.)
[0] https://files.radicle.xyz/latest/
[1] https://app.radicle.xyz/nodes/seed.radicle.garden/rad:z3gqcJ...
Not that curl bash is great, but it's not uniquely horrible when the goal is to run some unvetted code on your machine.
If you care about security, you have to either vet the code or trust the source. When you install through your package manager, you're trusting the maintainers. When you install from curl bash, a random website, or any unvetted software source, you are electing to trust the developers or site directly.
In bygone times, one might suffer from a truncation attack or otherwise end up running arbitrary code that's not what the vendor intended. Nowadays, there's really no security difference in curl|bash vs downloading a package and running it. Or, indeed, installing using `cargo install`.
That doesn't mean I'm happy running it, but my argument against it is less a security argument and more a predictability one: I want to be able to cleanly uninstall later, and package managers normally provide more consistent support for uninstalling than an arbitrary shell script.
This got down-voted so fast! :)
Serious question though: how much budget was spent on Radicle, how many people did work on it, and who is using it ?
I'm working in the crypto industry and I had the same impression.
Last time I heard about Radicle was the last bull market. Then it was silent in the bear, which is kinda strange, since everyone is always saying, bear markets are for building and Radicle certainly is a builder tool.
so many good memories of that software but for some reason I'm remembering a red theme.
Pijul is a great project indeed :)
[1] https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3trNYnLW...
This is not a criticism, and I could be wrong about this, but doesn't the mit license allow anyone to essentially bypass any extra responsibilities provided for in the Apache license? Specifically I'm thinking of the patent license grant provisions. I don't think the MIT license has anything to say about patents.
And if that is the case then why not just license it MIT?
You already have Bittorrent for distributing files P2P. We "just" need an extra layer for discovering new updates/patches so that files can dynamically update/grow. These two problems seem fundamentally decoupled. The "git forge" aspect seems to be another fundamentally separate layer on top of that
If that's what you've managed to pull off, that's like a way bigger deal than a p2p gitforge (not that that isn't super cool in itself)
I guess architecturally why does it need to be coupled to git and a git forge?
$RAD is the token of the organization that has been funding Radicle over the years.
And it wasn't free on my host me either :). Indeed 8080 is maybe not the best port to select for this app, because it is more likely used than "some other" port.
That is the default port for `radicle-httpd`: an HTTP API that would allow you to authenticate (using your public/private key pair, that is stored on your machine), so that you can perform actions on the web-based interface as a specific user, through your local radicle node.
Radicle can support a federated model, where known major seeds are connected with multiple smaller clusters. Radicle supports also completely self-sustaining and disconnected clusters of nodes networked between themselves within that cluster. And of course any other network topography in between.
There's a promising active proposal to establish a dedicated new Radworks Organization tasked with solving the incentivization and reward problem for seeds. https://community.radworks.org/t/discussion-rgp-22-start-the...
Additionally, similar to how one can "star" a repo on GitHub, one can "seed" a repo on Radicle. "Starring" a repo is often a toast of support, akin to an emoji reaction, with little more effect other than that, but in Radicle "seeding" a project, goes beyond incrementing a vanity metric: it actively supports propagating that project across the Radicle network. The count of seedings per repo can also be used as a differentiator between original and "copy-cat" ones.
What are the capabilities?
If a node is down, would other nodes step in? Where's stuff stored? How is it replicated?
https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3trNYnLW...
and as such, it makes for a poor user experience on the web.
(when you're just downloading files over P2P, this isn't an issue or noticeable - but when you're interacting with a web site, it is)
EDIT: why the downvotes? I'm just asking a question.
Because the synchronization protocol (backed by Git) is operating in the background, web frontends are always just querying local data, so it's actually quite fast. You can try browsing the linked repository and see for yourself.
If so, I'm glad that it completely failed and they decided to focus on the actual product of a 'P2P GitHub'.
Although stay away from their 'drips' crypto thing, looks like a tax and accounting nightmare for individuals and businesses.
I fail to see what `git rebase` has to do with issue trackers, project boards, wikis, repository notifications, or any of the other things that GitHub does. I use git forges as well as `git rebase`. Neither of these things precludes the other.
You can technically coordinate many of the other things through external tools like email, but email sucks, and there is real value to having them all in one place.
Obviously, I'd rather have all these things part of the repo itself, like with Fossil. What's what Radicle is trying to do, it looks like.
Also, git over yggdrasil should be easy because there are just ipv6 addresses. And, in the worst case, I think 6to4 tunnels would work.
https://geti2p.net/en/blog/post/2020/03/06/git-over-i2p see "Third: Set up your git client tunnel"
But like most things in the I2P ecosystem, not seamless.
Does this suffer from the code search problem, or are there plans to somehow introduce that?
The main problem of decentralized and federated code management projects is that I still go to github (not even gitlab) when I want to see what other people do, how they use a lib or something, and I can search issues, too.
So we obviously can't have each of our small servers serve code search requests from all the world's developers.
...a sync-and-search-only project is probably a job for someone like the EFF, or non-profit orgs that already have sufficient funding... has anyone heard any talks in that regard?
curl | bash is the recommended way to install.
The first three paragraphs of the guide has a longer motivation: https://docs.radicle.xyz/guides/user
Downvoters: do you not think their monetization strategy is important to potential users? Surely their investors didn’t throw that money at them out of the goodness of their hearts, and surely it’s apparent how that could affect their users in the long run.
Crunchbase said they raised at least 12m as a “fully decentralized code repository”. I’d say presenting your open source project without saying it’s VC-backed is the only “VC-Brained” thing happening here.
(there was a time _when that comment was the default type around here_, actually)
Over the past few decades we've seen many cynical capitalists riding the wave of "peer to peer open source" for personal gain. It's absolutely within scope to discuss how a company's business model may affect their ability to deliver on the supposed mission.
Codeberg is like GitHub.com, GitLab.com, or sr.ht: a centralized hosted solution.
sr.ht chooses another approach. You only need an email to submit codes, file issue, join discussion, etc. From perspective of source hosting, it is centralized. But, from perspective of project collaboration, it is decentralized.
Well, at least you don't need a name or a certificate for the server, I assume its id works as its cryptographic identity.
I know this movement since Github started with their "doubtful code scanning" that people are looking towards alternatives.
Not the least: good job!
So this is just a web interface to git? Like gitlab?
- "In botany, the radicle is the first part of a seedling (a growing plant embryo) to emerge from the seed during the process of germination.[1]"
I'll just mention that etymologically both "radical" and "radicle" come from the Latin "radix", meaning "root".
I greatly disapprove of the fashion of naming projects with common words. Names like Flickr or Google or Linux or Inkscape are effortlessly unique. Names like Snowflake are self-defeatedly commonplace.
2. Domain ends with the nonsensical .xyz, my email server would block all email traffic from them.
3. The default dark theme isn't readable by about 40% of the human population. It can be changed to a light theme, that's nice, but the light theme is some sort of puke light purple.
4. "Run the following command and follow the instructions to install Radicle and get started." I have to use your custom tool called "rad"?
No thanks. Even though GitHub is owned by Microsoft, I'd rather use it.