Hacker News Reader

Comment by amelius | Hacker News Reader

Time for a (truly) decentralized version control system?

Yeah, like Git or something!

I don't know if it is ironic, but the vcs is decentralized. The main issue is project & code management (bug tracking, issue, planning, merge request, review UI, ...). But here we also have a lot of solution : Gitlab, Redmine, Savana, ... But Github give your project exposure to a lot of potential contributor, and tend to be used as an extension of your CV (many recruiter contacted me because of my activities on GH ...). Lets be honest, the social network side of GH is one of its very important side.

> the social network side of GH is one of its very important side.

Exactly, and it's always the social network side of things that causes trouble when it's centralized. It's exactly our social interactions that we need to be free from central control in order to have any real freedom.

Then how about using the social media functions of GH, and keeping the source elsewhere (to the extent possible)?

How is git centralised? Just self-host with Gitlab, Gitea, et cetera.

Those are still centralized, i.e. there is one host that belongs to some person or org that's the main upstream repo and which can be hit with a takedown reqeuest. Git itself can be used in a truly decentralized way by having the main repo on IPFS or the like, though.

Edit: Also your sibling posts have pointers to projects with real decentralization, such as ForgeFed.

What do you mean with "real" decentralization? Git is as decentralized as you can get. You don't need IPFS to make it decentralized, it's already there. It was designed that way.

A lot of people are confused about this because GitHub and GitLab are the only intermediaries they've used to collaborate with git. If that applies to you and you would like to know better, read this: https://drewdevault.com/2019/05/24/What-is-a-fork.html

I was pretty clear in what I said: Gitea and Gitlab are centralized.

Git itself is neither centralized nor decentralized by design, it merely provides an infrastructure for replication and is agnostic about whether or not there is a "center" to the space of replicas. It depends on how you use it... but in practice the way it is used in nearly all projects is that there is one "main" (authoritative) upstream repo for a project, and that creates a point of centralization unless you put that repo on IPFS.

Yes, you could also completely forgo having a "main" repo, but how are the users then to find the "latest version" of your project? Who are you going to fork from, how do you discover collaborators? Git does not provide mechanisms for solving these problems; they're outside its scope. But some of the P2P and federated technologies such as IPFS do. With IPFS you can have a main upstream repo that's advertised without there being a host / person / org that can be hit with a takedown request. And other federated projects mentioned in this thread address other questions around collaboration that Github (as well as Gitea and Gitlab) address in a centralized fashion.

There is a difference between talking about a decentralized system, or about decentralized hosting of a centralized system. You are talking about the latter, but that is irrelevant if you have the former.

There is no "latest" version of a project in the decentralized model. As soon as there is one "latest" version that rules them all, you have centralized an aspect of the project and that immediately becomes a target for organizations like the RIAA. IPFS does not help here. Because in the end, someone must have the exclusive right to release a new "latest" version. This release mechanism becomes a single point of failure.

Sure, you can use use IPFS to create multiple copies of that new version to avoid having them taken down. But you also could just do `git clone` on a new server, as so many already have done. Creating copies and putting them up for download is not the problem.

If git is used in a true decentralized way, everybody has their own version of the project. No two have to be alike. Do you want to use youtube-dl to download porn, get the version with the right extension. Do you have moral objections to porn, get the version without them. Exactly like there is no "one" Linux, each distro has its own version, with the patches they think are important. This way, the RIAA could even release their own version of the tool. One that can download from Youtube, but not video's that are subject to the copyright they want to uplhold.

Users would not have download the tool directly from that one developer/team, they could download it from whoever they trust to have their best interests at heart. That is what decentralization means.

I'm amazed at the number of people who can't seem to grasp the difference between Git and GitHub/Gitea/Gitlab, on Hacker News of all places.

Git has no idea about a "the main upstream repo", that's a Github-et-al invention. Git will happily push/pull to a bunch of other peoples' repos with no "main" or central part at all.

If you've grown up in the Github era you've probably never seen multiple remotes, but here you go: https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remot...

They’re out there. ssb-git is git over the scuttlebutt protocol.

with fossil you can use the built-in http server to quickly clone a repo, then just do `fossil server` to run a new host. Easy to decentralize the interface as well as the code.

https://man7.org/linux/man-pages/man1/git-instaweb.1.html

> version control system?

Better to refer to them as 'code forges', the central locations where clone your git repo from, and that have additional features such as issue tracker, team boards, and what-have-you..

> decentralized

The code forges themselves (github, gitlab, gitea, sourcehut, vervis, etc.) are not decentralized, but the open ForgeFed protocol, under development at https://forgefed.peers.community (an extension of ActivityPub), facilitates decentralization of forges.

---

TL;DR Talking about decentralizing GH / VCS always leads to (correct) reactions such as 'git is already decentralized'. Code forge interactions need to become decentralized too.

ForgeFed is a decentralized version control system under development.

https://forgefed.peers.community/

This is what we need (recently learned about it).

I wish this had more traction and progressed more quickly. Though of course it is a good thing not to rush the specification.

This is just a federation protocol, so it doesn't really solve the problem: federated systems are just a way to make it easier to interoperate between a number of separate instances, but every individual "thing" (in this case, a repository) is still going to be hosted on an instance that can be taken down (and sure, it could be put on another one, but then you didn't solve the problem); what you want is a "truly decentralized" (the word "truly" in parentheses was a critical part of the comment you were replying to) and really hopefully "distributed" revision control alternative, not merely a mechanism to "enable interoperability" (the phrasing from their website) between existing services (which should make the issue clear: if no existing service could host the repository in question, then interoperating between existing services doesn't suddenly cause stable hosting to appear).

The term you're looking for is "censorship resistant".

China has been on the forefront of this, both in terms of censorship and censorship-resistance.

Unfortunately for the mice, the cats are winning.

Reply on news.ycombinator.com