[vouaobrasil]

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.

[hnlmorg]

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.

[vouaobrasil]

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.

[chriswarbo]

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.

[em-bee]

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.

[chriswarbo]

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.

[hnlmorg]

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.

[mikl]

Sure, but https://fossil-scm.org/ already does the “without requiring a server” part, without all the extra crypto-nonsense.

[vouaobrasil]

True. But this is for Git.

[strogonoff]

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.