Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dgit: Git with decentralized remotes

github.com

Post reply on HN
Print view View original

31–40 of 87 posts

Re: Dgit: Git with decentralized remotes

#31

Post by zonotope »

NickBusey wrote: post #29

This is cool, but is anyone aware of a system that is like GitHub/GitLab, but PR/MRs and commits are actually voted on by the community rather than a handful of maintainers? Something like the way DAOs are supposed to work, but applied to code?

Yeah, it's still early days, but that's part of the eventual plan for dgit. We're starting with decentralized git remotes, but we will eventually enable DAO like functionality like paying in to repos to support them, voting on things like feature/pull requests, and automatic payouts when an independent dev gets one of their pull requests merged.

Re: Dgit: Git with decentralized remotes

#34

Post by kazinator »

zonotope wrote: post #17
lucideer wrote: post #16

As others have commented, this appears to be a decentralised alternative to GitHUB rather than Git itself (which is already decentralised). For a similar project, see git-ssb https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoy...

Another Dgit deve here. You're right. Git is decentralized, but most people use centralized git remotes like GitHub. Dgit makes using a decentralized git remote easier. Eventually we'll build more decentralized alternatives to other GitHub features, but the most important value proposition that GitHub provides now is as a git remote, so that's what we started with. We've provide a GitHub action that allows you to use…

Only problem is, according to a conventional understanding of git, there is no such thing as a "decentralized git remote"; maybe can you do a better job of explaining what that is?

Every [remote ...] entry in your .git/config points to some concrete URL. Even if you have a plurality of these (thanks to git being decentralized), each one of them is a single location that could be a single point for some activity.

Re: Dgit: Git with decentralized remotes

#35

Post by pdonis »

zonotope wrote: post #26
pdonis wrote: post #23

Earlier quoted context omitted.

> a decentralized git remote How is the git remote you provide "decentralized" as compared with the remote provided by GitHub?

Anyone can run a Sia node, and anyone will (eventually) be able to run a Tupelo node, but only GitHub manages GitHub. It's decentralized because these networks were designed not to be managed by a single entity, unlike GitHub.

GitHub's source code is open, so anyone can run a GitHub node too. The node that GitHub itself runs became a centralized place for people to share development because of network effects, not because anything in the code itself prevents more than one node from existing.

Re: Dgit: Git with decentralized remotes

#36

Post by tylersmith »

kazinator wrote: post #34
zonotope wrote: post #17

Earlier quoted context omitted.

Another Dgit deve here. You're right. Git is decentralized, but most people use centralized git remotes like GitHub. Dgit makes using a decentralized git remote easier. Eventually we'll build more decentralized alternatives to other GitHub features, but the most important value proposition that GitHub provides now is as a git remote, so that's what we started with. We've provide a GitHub action that allows you to use…

Only problem is, according to a conventional understanding of git, there is no such thing as a "decentralized git remote"; maybe can you do a better job of explaining what that is? Every [remote ...] entry in your .git/config points to some concrete URL. Even if you have a plurality of these (thanks to git being decentralized), each one of them is a single location that could be a single point for some activity.

I don't know anything about dgit yet but regarding this general idea: what you say true from the perspective of your git client but that URI could be a gateway to a decentralized backend. If you're familiar with IPFS, imagine IPFS gateways for git repos. The gateways themselves are centralized but they're just feeders into a decentralized network.

Re: Dgit: Git with decentralized remotes

#37

Post by remram »

pdonis wrote: post #35
zonotope wrote: post #26

Earlier quoted context omitted.

Anyone can run a Sia node, and anyone will (eventually) be able to run a Tupelo node, but only GitHub manages GitHub. It's decentralized because these networks were designed not to be managed by a single entity, unlike GitHub.

GitHub's source code is open, so anyone can run a GitHub node too. The node that GitHub itself runs became a centralized place for people to share development because of network effects, not because anything in the code itself prevents more than one node from existing.

GitHub is not open-source, though alternatives like GitLab and Gitea are.

Re: Dgit: Git with decentralized remotes

#38

Post by tylersmith »

jedimastert wrote: post #2

I'm a little confused. Isn't git already decentralized? Like, most of the time there one true repo everyone else grabs from, but it doesn't have to be. What am I missing? Edit: oooooh, this takes the centralization away from Git Hub . I feel like that's non obvious from the name, but I could be wrong.

Git is decentralized like the web is decentralized. The architecture supports it but the infrastructure for using it in a truly decentralized way is severely lacking compared to the options for using it in a more centralized way.

Re: Dgit: Git with decentralized remotes

#39

Post by BoorishBears »

pdonis wrote: post #35
zonotope wrote: post #26

Earlier quoted context omitted.

Anyone can run a Sia node, and anyone will (eventually) be able to run a Tupelo node, but only GitHub manages GitHub. It's decentralized because these networks were designed not to be managed by a single entity, unlike GitHub.

GitHub's source code is open, so anyone can run a GitHub node too. The node that GitHub itself runs became a centralized place for people to share development because of network effects, not because anything in the code itself prevents more than one node from existing.

If you make your own GitHub "node", it won't have any of the information GitHub.com has. If I'm understanding correctly, the idea with this is every "node" has a portion of a canonical truth.

Not sure that would still get people to use it, but at least more feasible than making your own GitHub instance in relation to growing network effect

Post reply on HN