Radicle: Open-Source, Peer-to-Peer, GitHub Alternative
app.radicle.xyz
app.radicle.xyz
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.
It's peer to peer, anyone using the protocol is entitled to share and collect as much data as the protocol permits, and the founders have no more power than any other user.
It's way less sketchy than anybody operating a server and asking you to trust that they're doing so responsibly--which is pretty much everybody.
I don't think that everything can or should be made zero-trust. But if this can, then that's a win.
It’s dealing with a company where you agree to a policy that describes how they can use your data. That means you have legal recourse if they violate that agreement.
It also means you know who actually has your data which isn’t the case with these federated networks. Every entity that has your data on their server is another entity can use it in a way you don’t agree with
On top of that, the alternative solutions are pretty clear how they make money.
I don't know these people, maybe they are indeed up to something nefarious, but their design is inherently more trustworthy than federated or hosted solutions. If I must chose between transparency into finances and a nonhierarchical design which presents no high value targets for corruption to focus on, I'll take the better design over the financial transparency every time.
If they turn out to be actually shady I can just configure my node not to talk to them or their friends and keep on using it, which is a lot more than can be said for most of the alternatives.
Besides, it's a publishing platform. What is this "your data" you're talking about? The whole point is to spread it far and wide and to collect contributions from far and wide.
> 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?
(P.S. I am working at Radicle)
But please note that you can also choose a "block everyone, follow just the good ones" (i.e. a selective) seeding policy [1]).
[1] - https://docs.radicle.xyz/guides/seeder#a-selective-seeding-p...
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
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?
Although I would be careful and make sure you understand what it is doing to your branch namespace. Even though in the worst case it would not save any space over directly committing binaries, they are in orphan branches that can be pruned without rewriting history.
But even so, you can just use any number of git-annex special remotes to bypass using git for sharing files.
They may eventually add first-party support for git-annex. But nothing is stopping you from using it now.
For example, allow users to be able to subscribe to specific repos or specific topics or specific people etc
And this has a legacy roughly as long as BitTorrent itself. The fact that BT never established a footing in other use cases (even those where you would think it would be a great solution) is telling.
Windows Update also allows the user to opt in to use a non-bittorrent protocol for peer-to-peer delivery of updates to other Windows users. But of course, it's not true Bittorrent.
No need for crypto/digital currency whatsoever.
> 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.
Having to deal with individual users of various software I'd sometimes resort to using WSL, but this isn't an always acceptable way.
To shed more light: some of the users of the system I'm talking about are hospital researchers. These people are very limited in terms of choices they can make about their computers. While it could be possible sometimes to convince hospital's IT to install / enable WSL, this won't work all the time esp. because it, essentially, allows too much control for the otherwise very restricted user over their workstation. MSYS2 here has an advantage that everything can be packaged as a single program (Git is distributed in this way for example), which makes it easier on the org. IT. In principle, WSL can be used that way too (iirc. Docker does something like it), but you'd still need a bunch of Windows-native wrapping for things to work (i.e. I understand that there needs to be at least one service process that does the peering).
[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.
Although maybe this approach is cheating because it's relying on https and not some kind of hash-linked P2P magic (which would definitely require modifying nix to make work). I guess there's something similar to the IPFS gateway going on: somebody is hosting a bridge into radicle space. It would be interesting to get this working without dependency on that bridge.
Anyhow, modify your project's flake accordingly and your version of `rad` will track with that radicle repo. No curl-to-bash required.
Seems to work for git-remote-hg, anyway:
nix-repl> (builtins.fetchGit { url = "hg::https://www.public-software-group.org/mercurial/lfapi/"; rev = "34366bf575c8c77c8d3b76d32940c1658cb948a4"; }).outPath
"/nix/store/8dwyms22iwy4fq0b1593i34m88jk574j-source"
[0]: https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3gqcJUoA...
Nix itself has a plugin mechanism, but its rarely used (since it can harm reproducibility; and TBH that seems to be the only reason to use it, for those very rare situations that it's desirable)
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’m surprised the answer isn’t obvious to you, yet again maybe I shouldn’t be as I suspect you’re a nocoiner.
Distributed decentralized anything is fundamentally about censorship resistance. Understanding that, for me, make the answer as to why they are passionate about distributed decentralized version control … they are concerned about coming censorship attempts on software, which honestly seems pretty likely given the current authoritarian direction of western civilization in general.
I’d also speculate that your perception isn’t shared by everyone based on the large number of upvotes on this submission.
It is this radical idea that everyone can easily be an equal participant in the network and that they have power over what they want and don't want. Open source nature further helps you to adapt things - don't like our web UI local-first interface? Build your own one or adapt ours to your need.
As it happens there are many others like me, and this helps fuel our excitement and drive to get this out there.
also, i'm curious, what kind of adoption were you anticipating (some time ago and now) and did the result align with it?
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?
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...
This looks like an interesting approach. I have question, to avoid copy a large .git project, we have partial cloning and cloning depth. If `cobs` grows too large, how can we partially clone it? Like select issues by time range?
Emphasis mine. Doesn't seem to be it seening as this is yet another home grown issue storage.
What’s the alternative? That at least N projects cooperate and agree on a common design before they do the implementation? (Then maybe someone can complain about design-by-committee.)
The alternative to that would be the git project itself coming up with an implementation. They have reasonable experience working with the Kernel, and the creation of git itself seems to have worked reasonably well -- although I'm not sure I would want to use something Linus considers ergonomic :)
Without such a group you might just send a few emails to mailing list, get shrugs about how that plan “looks good” with little real interest, and then have to discuss this big plan in every future patch series that incrementally builds such a thing into Git itself. Mostly why such code should be incorporated and how it will pay off when it’s all ready.
The Git tool itself—and the project by extension—is per now very unopinioated about whole-project solutions like this. The workflow that they themselves use is very loosely coupled and pretty much needs bespoke scripting by individual contributors, which I guess is telling in itself.
That would be ideal, yes. You should solicit comments from the greater community before setting the format in stone. But the very minimum would be to build on existing attempts at issues-in-git like [0] instead of reinventing the wheel unless you have a very very very good reason.
I'm not claiming these tools are the best, or anything. Just that existing standards can work very well, and are a good foundation to build up UIs or whatever; rather than attempting to design something perfect from scratch.
My fork of Artemis, patched for Python3: http://www.chriswarbo.net/git/artemis
Emacs config to trigger message-mode when emacsclient is invoked as EDITOR on an Artemis issue: http://www.chriswarbo.net/git/warbo-emacs-d/git/branches/mas...
An example of HTML rendered from Artemis issues: http://www.chriswarbo.net/git/nix-config/issues/threads.html
If someone wanted to come along and define a way to embed Fossil wikis/issues as a COB then they could be replicated on the Radicle network and it's then up to application developers to load and interpret that data.
I think this is cool because it essentially allows developers to extend the Radicle ecosystem easily and define new workflows! However, that does not avoid our XKCD problem stated above ;P But hey, sometimes that's the beauty of these things -- we're given the power to define our own workflows and not locked into something everyone complains about coughGitHub branches PR flowcough
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.
That is exactly what I'm suggesting.
There are probably an infinite and always growing and changing number of repo-adjacent things similar to the handful of added features that github currently tacks on to git.
I think it doesn't make sense for git, already complicated enough, to try to do all of that other related stuff, however related.
Maybe in fact git is already doing too much meaningful metadata work directly itself, and should instead try to switch it's current metadata into some kind of generic interface that other software could hook in to better?
So rather than git managing, say, issues, git just manages data. Not merely a db, it would facilitate associating high level feature data like issues and ci and conversations with low level commit data. An issue tracker would just be one of many clients using the interface.
git itself should probably not know very much about the data other than how it is associated to some commit. IE, the actual meaning of the data is either only in the consumer, or perhaps is some agreed standard that multiple consumers adhere to and understand, or perhaps comes with it's own schema definition like dtd or protobuf. Or all of the above, a paid product could have data only it understands, and other software could use standardized data, all stored in git at the same time. Multiple different consumers could use the same generic interface to their own data.
Because these add-on related functions are probably not universal or done being invented. Tomorrow there will be 5 new things you want to attach to a repo besides what github provides today, and so without even knowing what they are, that's how I know it's wrong for git to provide the features itself.
But managing the data without caring what the data is, that could totally be a new built in git function, where you give git itself one new function and interface, and an open-ended number of new feature-providing consumers all just use the same underlying git feature in whatever way they want.
Other than that the only other new thing I think that might be right to add to git itself is a proper way to manage large binary assets.
Git is just a mechanism for storing plain-text data as a series of commits. The underlying data are just blobs of bytes. So all data is Git data and Radicle takes full advantage of that.
The "special" data in Git would be `refs/heads`, `refs/remotes`, `refs/tags`, and the lesser known `refs/notes`. Radicle doesn't touch those directly, we still allow the use of Git tooling for working with that data.
It then extends on top of these by use `refs/rad` and `refs/cobs` for storing Radicle associated data, using all of Git's mechanisms that it provides to do so.
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.
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.
With that being said, your example feels pretty far off the mark. You might be able to phish using a similar looking identity, but that's completely unrelated to the trustworthiness of the platform. It's not as though you'll manage to somehow phish Github into showing someone else's trustworthy work history on a spoofed identity.
You don't need to trick github, that's just how it works by design. Anyone can upload any repo to github. There is nobody checking the repo isn't stolen or fake. Github does not claim to be vouching for anyone. At most they will delete malware and obvious scams if it happens to comes to their attention.
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-...
> 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.
[0]: https://github.com/libgit2/libgit2/blob/ac0f2245510f6c75db1b...
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.
I don't deny that your improvements can benefit certain teams/developers but I feel like there are very few people that would actually care about them and they're not making use of alternatives.
Whereas having to trust people, especially as people cycle in and out over time can be inherently stochastic.
I understand that the disruption Radicle wants to bring is to divorce projects from their developers, but that sounds so foreign to me, that I can't wrap my head around it. I can see its use in some cases: abandoned projects, unethical behaviour from maintainers, but not to the extent where a new platform is required.
Maybe that's why I'm being such a Negative Nancy. I hope u/cloudhead didn't consider my replies too aggressive. :)
Not looking to convince you of that or anything though... :)
I think there’s room for improvements in distributed or self-hosted git, but I think they exist more in the realm of usability than any technological limitations with the protocol. Most people don’t sign git commits because they don’t know it’s possible—not because it’s insecure.
The advantage of this is that (a) it verifies that the code is properly signed by the maintainer keys, and (b) it allows for the maintainer key(s) to evolve. Otherwise you’d have to constantly check the official website for the current key set (which has its own risks as well)
If I am on the internet there is no key or keys that I could definitively say came from the _real_ maintainers. I need to trust some source or sources for that.
In your model, committing to the repo requires a private key. This key claims ownership of the repo. If that key is lost or stolen I have lost ownership of that repo. With no out of band method to recover it.
If that key is unknowing stolen, ownership is switched to a new key, this is a pretty bad scenario.
Basically, I still always need to go to some other out of band source to verify that bad things have not happened.
The current state of key management has A LOT left to be desired, because `did:key` has no rotation and so if you lose your key then it's game over. We decided to go with something simple first to allow us to develop the collaboration experience as much as possible -- we're a small team so it's hard to tackle all of the large problems all at once, while also getting an experience that's polished :D
Key management and a general "profile" is high on our priority list after we have properly launched. A few of us think DIDs (https://www.w3.org/TR/did-core/) are a good way forward. In particular, `did:keri` seems very interesting because its method involves a merkle-chain log, which can be easily encoded in Git. It includes key pre-rotation -- meaning there's a key that's available to help recover if something goes wrong. It can also delegate to other people, so you can allow the safety of your identity and key be improved by third-parties.
That said maybe there are other DID methods or other methods in general that might better suit. Or maybe we're able to build something that can be more general, and just needs to essentially resolve to a public/private key pair and we don't care after that.
Would definitely be interested in the communities thoughts here :) Or if someone who's got expertise in the area wants to chip in, hit us up ;)
You have just changed the requirement from knowing the maintainers public key, to knowing a different public key. Sounds pretty much the same problem to me.
Updates to the delegate set (read: maintainers) can be made, let's say adding a new delegate. This change is signed by a quorum of the current set of maintainers. This change is kept track of in the Git commit history, so these chain of actions can be walked from the root and verified at each point.
Similarly, a delegate can be removed, the project name changed, etc.
Forking is only necessary if there is a disagreement between maintainers that cannot be resolved so one of them goes off to create a new identifier to differentiate between the two. At this point, it's up to you to decide who you trust more to do a better job :)
Debian seems to be quite good at this.
https://wiki.debian.org/Keysigning
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...
Fossil (https://fossil-scm.org) embeds issues, wiki etc. into project repository.
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).
The most obvious example is DNS, which is technically capable of this, but is mostly not set up in the ways we'd want. It's pretty centralised: so whilst anyone can host their own DNS servers, serving any data they like, it's unlikely the "main" DNS network will connect to it; and will consider you malicious if your data disagrees with the centralised records. Things like DNSLink can be useful for associating as DNS name with names in other systems, but that's still vulnerable to hijacking/poisoning without an out-of-band way to verify it.
The GNU Name System seems better suited, since it can use public keys for stable names, which therefore can't be hijacked/poisoned. Associating these to pet names is also less centralised, feeling more like /etc/hosts than "the" DNS; with recursive resolving, so e.g. I can look up "Yuzu" based on what you think it is, etc. That seems to provide a nice balance between decentralised control, versus relying on side-channels to find public keys. I'm currently experimenting with this.
There's also IPNS, but in my experience its lookups are incredibly slow and unreliable. It could get better, and I know various studies are being performed and experiments with different approaches and parameters are being tried, so I'm hopeful something will come of it.
As far as I remember, the main reason Radicle diverged from these approaches (and IPFS/IPNS in particular) was to allow peers to negotiate delta transfers, like (non-dumb) Git HTTP servers do. That's more efficient than using something like IPFS/IPNS, where the root address keeps changing, and we need to fetch a load of the Merkle tree to find out which blocks we already have.
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 masterThe 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?
Migrating 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
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.
Even what I mentioned about static typing I'm sure caused a blood-pressure spike in some readers, since some folks value the type safety and others consider it "line noise". Some people enjoy the double-quote free experience of yaml, others pound on their desk about the 7 ways to encode scalars and "but muh norway!!11"
But, taking our ragingly dumbass buildspec friend <https://docs.aws.amazon.com/codebuild/latest/userguide/build...> as a concrete example, how in the holy hell did they invent some build language without conditionals?! I'm sure the answer is "well, for our Amazon-centric use case, you're holding it wrong" but for someone coming from GitLab CI and GitHub Actions which both have "skip this job if today is Tuesday" it's a pretty glaring oversight
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.
I appreciate you think you have, but you haven't. Appeals to vauge lofty notions of digital soverignty and other political values is not what i'm looking for and doesn't really mean much. I'm more looking for a threat model. What does the network accomplish? What are its limits? What are its intended properties?
> Additionally though, Radicle offers a level of censorship resitance and disruption tolerance that GitHub cannot offer.
That seems unlikely (at least as it stands now). Pretty sure it would be much easier to DoS the entire radicle network than to DoS github. It all depends on who you think your attacker is. Github has an excellent track record of standing up to china (for example nytimes archive on github is primarily about bypassing the great firewall of china) it is much weaker on DRM circumvention. All these things depend on how you define them. If you don't define them, and rigorously analyze them, then your censorship resistence is probably wishful thinking.
From what i read in their docs, that is not how they are defining seed node.
> A seed is a node that hosts and serves one or more projects on the network.
I have not read the entirety of their documentation in great detail, but what I did glance over, I did not see anything particular special about seed nodes other than they host and serve projects. And obviously there is a bit of plumbing required for that.
>
>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.
[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.
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.)
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...
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?
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.
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.
(there was a time _when that comment was the default type around here_, actually)
Codeberg is like GitHub.com, GitLab.com, or sr.ht: a centralized hosted solution.
I know this movement since Github started with their "doubtful code scanning" that people are looking towards alternatives.
Not the least: good job!
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.
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]"
And don't forget Thread! Pretty annoying when you're trying to learn about Thread on ESP32 and you just get stuff about threads.
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.
But what you can expect from a language that allows one to tape a talk, or to circle back about an ask?
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.