5 ms·

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 sup

by mikl 2y 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?

vouaobrasil 2y ago
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 2y ago
  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 2y ago
    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.
    - hnlmorg 2y ago
      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.
    - chriswarbo 2y ago
      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 2y ago
        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 2y ago
        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.
- mikl 2y ago
  Sure, but https://fossil-scm.org/ https://fossil-scm.org/ already does the “without requiring a server” part, without all the extra crypto-nonsense.
  - vouaobrasil 2y ago
    True. But this is for Git.
    - strogonoff 2y ago
      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.
dotancohen 2y ago
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.
- samsari 2y ago
  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.
  - kevindamm 2y ago
    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.
- vinnyhaps 2y ago
  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.
baq 2y ago
> what real world problem is it supposed to solve? having to self-host anything?
vaylian 2y ago
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/ 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.
- mikl 2y ago
  > 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.
- Jhsto 2y ago
  Unless we'd default to mailing lists and email patchsets would be more used, similar to sourcehut.
- treyd 2y ago
  What do I do if my signing keys are compromised? Should every developer get the equivalent of a hardware wallet to reduce that risk?
forgotpwd16 2y ago
>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 https://radicle.xyz/guides/protocol#introduction This provides comparison and reasoning.
CaptainOfCoit 2y ago
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.
saurik 2y ago
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.

by mikl 2y ago

vouaobrasil 2y ago

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 2y ago
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 2y ago
  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.
  - hnlmorg 2y ago
    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.
  - chriswarbo 2y ago
    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 2y ago
      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 2y ago
        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.
mikl 2y ago
Sure, but https://fossil-scm.org/ https://fossil-scm.org/ already does the “without requiring a server” part, without all the extra crypto-nonsense.
- vouaobrasil 2y ago
  True. But this is for Git.
  - strogonoff 2y ago
    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.

dotancohen 2y ago

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.

samsari 2y ago
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.
- kevindamm 2y ago
  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.
vinnyhaps 2y ago
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.

baq 2y ago

> what real world problem is it supposed to solve? having to self-host anything?

vaylian 2y ago

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

mikl 2y ago
> 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.
Jhsto 2y ago
Unless we'd default to mailing lists and email patchsets would be more used, similar to sourcehut.
treyd 2y ago
What do I do if my signing keys are compromised? Should every developer get the equivalent of a hardware wallet to reduce that risk?

forgotpwd16 2y ago

>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 https://radicle.xyz/guides/protocol#introduction This provides comparison and reasoning.

CaptainOfCoit 2y ago

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.

saurik 2y ago

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.