Hacker News new | ask | show | jobs
by mikl 780 days ago
They keep advertising this thing on here, but they never explain what the big benefit is.

Everyone can already self-host Gitea or Gitlab, and Git repos are super easy to clone, so what’s the point of all the peer to peer stuff?

ie. what real world problem is it supposed to solve?

7 comments

One of the problems of self-hosted forges is that spontaneous collaboration is cumbersome, because you need to keep track of your accounts across different self-hosted forges. Some people are working on https://forgefed.org/ to make this less of an issue, but Radicle is a different approach, where the entire repository ecosystem becomes distributed and people identify themselves with cryptographic identifiers to interact with the network as a whole instead of individual forges.
> because you need to keep track of your accounts across different self-hosted forges

Ah, that’s not that much of a problem these days, where password managers (and failing that, SSO with Facebook/Google/etc.) has become wide-spread.

And unless everyone moved to Radicle, it’s just one more system you need to track authentication info for.

What do I do if my signing keys are compromised? Should every developer get the equivalent of a hardware wallet to reduce that risk?
Unless we'd default to mailing lists and email patchsets would be more used, similar to sourcehut.
Git was already designed from the outset specifically to be peer to peer. The central server is the addition to that model, not the other way around. I have not looked into this project, but pitching whatever it is as P2P for Git just sounds like the devs learned about Git though GitHub and don't fully understand it.
We're quite aware that Git is a distributed code collaboration tool, even trying out the email based flow in the past :)

You may notice that the title is "peer-to-peer code collaboration stack built on Git", emphasis on "built on". We're using Git as a storage and transport mechanism for code collaboration data. So we're building a local-first tool for the social data, e.g. patches and issues.

Alternatively, the fact that the very first thing basically everyone who isn't Linus has done with vanilla git is introduce some kind of central authority might suggest that what git was "specifically designed for" is more of an outlier than you want to admit.

Everyone knows Linus invented and "specifically designed" git as a drop-in tool for his existing email-patch-based kernel development workflow, which is not how 99.9% of the rest of the world prefers to operate these days.

The difference there is that code can still be pushed (or pulled) between the git repo and the new centralized instance after forking. Anyone coming from pre-git centralized source control (or shudder the NAS of periodically rsync'd folders) recognizes that this represents a significant difference from that earlier world.

On topic, though, I have no idea what Radicle's value-add is, though.

According to their documentation "nodes can run on a personal computer without requiring a server". That sounds better than self-hosting to me, which requires the installation of various components like Apache, SQL, PHP, etc. Seems more like bittorrent for code, which sounds like it could actually be useful.

Ideally, we would have a solution to collaborate on projects peer-to-peer that handles some basic Github-style stuff without having to use Github at all.

That’s literally what git is designed to do from the outset. That’s why it’s called a decentralised version control system.

I’m sure this project brings something new to the table but they’d need a better elevator pitch than “peer-to-peer” to explain that.

But git is not user-friendly. You have to figure out how to push to people directly, and that isn't obvious to a commoner like myself. It would be great to have a nice front-end like Transmission is for bittorrent that makes the experience seamless.
Git works over email; it works across folders (including remote ones); it can read/write several standalone file formats (patches, bundles, etc.) that can be sent via carrier pigeon, etc. As far as I'm aware, there are no technical problems with "push[ing] to people directly" (or likewise allowing others to pull from you).

There is a technical problem in the P2P setting, where it's not just one individual connecting to another. P2P protocols which just replicate data, like Bittorrent, can't negotiate a delta when pushing/pulling, so users have to keep pushing/pulling the entire repo. Radicle's network is smarter, allowing deltas to be calculated.

They also seem to be proposing many other things, which I'm more skeptical of; but at least that point seems valid.

Bittorrent, can't negotiate a delta

what do you mean by that? as long as you don't recompress the git storage, bittorrent will only transfer the missing blobs. the only problem is that for each change a new torrent hash needs to be created. but you can stuff a new torrent with the git repo you already have and then bittorrent will only transfer the missing blobs just like git does.

Yes, only the missing file data needs to be sent. Working out what's missing is the problem, since protocols that aren't aware of git's structure (blobs, trees, commits, etc.) cannot exploit that knowledge to e.g. walk up from each ref and stop when we hit existing ancestors. Instead, they're stuck comparing the file contents of two entire copies of a repo (via their Merkle trees). That's probably not a big deal for smaller projects (e.g. I've played with hosting my own git projects on IPFS), but it's a lot of overhead for projects like the Linux kernel with massive histories, lots of refs, many developers frequently pushing and pulling many changes, etc.
I agree. However there are already plenty of frontends to git and this isn’t marketed as one of them. Perhaps intentionally because of my earlier point that there are lots of frontends already? But focusing on the p2p aspect doesn’t do any better of a job explaining what this project does.
Sure, but https://fossil-scm.org/ already does the “without requiring a server” part, without all the extra crypto-nonsense.
True. But this is for Git.
Since Radicle does not interoperate with Git servers (it uses “Radicle nodes”, and you must run one in order to use Radicle), adopting it is approximately as good as adopting a new VCS; so if there is a VCS that addresses the pain points without involving the crypto nonsense, then that’s the winner. One can potentially even implement a script that populates a Fossil repository history from Git’s and a Git-like front-end CLI/GUI abstraction on top of Fossil’s, making migration as easy as pull from one remote remote and push to another.
Who are "they"? Submitter seems unrelated to Radicle. And what you mean "advertising"? It's a normal HN item, posted like all the others, upvoted to the frontpage like all the other frontpage items.

> ie. what real world problem is it supposed to solve?

Seems pretty clear from the submitted page.

Problem: centralized code hosting platforms [...] single entity(ies) controlling the network(s)

Solution: Repositories are replicated across peers in a decentralized manner, and users are in full control of their data and workflow.

Literally the first paragraph on the page.

Nothing that requires the user to keep knowing your new URL is ever going to be peer-to-peer: the domain name system is fundamentally and irretrievably a hierarchical system; the ramification of this, of course, being that it supports your well-known URL being attacked or censored and your only workaround is to try to rapidly change your URL constantly... but now, no one can find you consistently, and so you cannot collaborate with anyone over time.
>Everyone can already self-host Gitea or Gitlab

But self-hosting limits exposure, that Github.com/Gitlab.com provide.

>Git repos are super easy to clone

Git is meant to version your code, not issues, pull requests, etc.

https://radicle.xyz/guides/protocol#introduction

This provides comparison and reasoning.

> what real world problem is it supposed to solve?

having to self-host anything?