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?

https://git-scm.com/docs/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.

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. :)

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.

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.

> 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.

From https://shattered.io/

[0]: https://github.com/libgit2/libgit2/blob/ac0f2245510f6c75db1b...

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.

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 :)

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.

[0] https://github.com/MichaelMure/git-bug

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.

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.

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).

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.

[1]: https://github.com/MichaelMure/git-bug

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.

> 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, allow users to be able to subscribe to specific repos or specific topics or specific people etc

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.

[1]: https://github.com/domo141/git-annex-remote-git-aafs

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.

https://wowpedia.fandom.com/wiki/Blizzard_Downloader

(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

> 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.

[0] https://docs.radworks.org/community/ecosystem

[1] https://www.drips.network/

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.

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.

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.

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.

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...

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).

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.

As it happens there are many others like me, and this helps fuel our excitement and drive to get this out there.

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.

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.

  git pull github master
  git push rad master

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

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.

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

> 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.

>

>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...

[4] https://rvm.io/rvm/install

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.

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

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.

[0]: https://en.wikipedia.org/wiki/Peer-to-peer

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.

https://en.wikipedia.org/wiki/NESticle

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 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.

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?

$RAD is the token of the organization that has been funding Radicle over the years.

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.

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.

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...

[0]: https://www.gerritcodereview.com/

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.

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.

[1] - https://www.inkandswitch.com/local-first/

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)

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.