top | item 22684945

Dgit: Git with decentralized remotes

147 points| QCSmello | 6 years ago |github.com | reply

85 comments

order
[+] lucideer|6 years ago|reply
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...

[+] zonotope|6 years ago|reply
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 GitHub's other features until we build more decentralized alternatives
[+] jedimastert|6 years ago|reply
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 GitHub. I feel like that's non obvious from the name, but I could be wrong.

[+] zonotope|6 years ago|reply
git is decentralized, but most git remotes are not. This is a decentralized git remote that gets the best of both worlds. It's a _decentralized_ "one true repo".
[+] Tyr42|6 years ago|reply
With three simple steps you can create a decentralized mirror of your existing github project. All changes will be automatically propogated to the mirror version and the git services you depend on will be there when you need them.
[+] tylersmith|6 years ago|reply
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.
[+] kyberias|6 years ago|reply
It is very hard to understand what dgit really does when its using terminology (decentralized git) clearly incorrectly.
[+] unqueued|6 years ago|reply
I actually do p2p syncing of git repos almost every day, with git-annex's sync feature[1].

It is pretty clever, when you sync, it will push the current branch to every eligible remote into an unchecked out branch (master -> remote/synced/master), which gets merged when that peer syncs (or there can be a daemon that does it for you on the remote).

I use git for filesets and wikis, so true p2p is really helpful. I love seeing new stuff that can be done with git.

[1]: https://git-annex.branchable.com/walkthrough/syncing/

[+] cfstras|6 years ago|reply
The description says that my repo is uploaded to the "decentralized service Skynet" -- But I can't seem to figure out how one would participate in hosting this service. Does only Sia, the company, host nodes for Skynet? Or is this a plot to increase the visibility of Siacoin?
[+] cap10morgan|6 years ago|reply
dgit dev here. Good question. For starters, dgit is not 100% tied to Sia, it's just a great decentralized file hosting service so we started with it as the first default.

But to answer your question, anyone can host Sia nodes. Here are their docs on that: https://support.sia.tech/category/0OpBuOHIVD-hosting

[+] JohnJamesRambo|6 years ago|reply
It would be nice for Sia to be useful for something.
[+] oefrha|6 years ago|reply
Not being able to pull from or push to the git remote is pretty low on the list of problems when GitHub goes down. If that’s the main problem I’ll just set up gitolite on a server (and I do) and call it a day.

All the issue/PR discussions and CI/CD are the real problems, and this doesn’t seem to help at all, so good luck collaborating without changing your workflow when GitHub is down.

[+] cap10morgan|6 years ago|reply
Our setup process is a much lighter lift than standing up a server and installing gitolite on it.

But yes, if GitHub is down, then your workflow is going to change. We're hoping to close that gap down the road, but having a way to continue pushing and pulling with collaborators with a very quick setup seemed compelling to us. Not to mention the benefits that decentralization itself brings.

The vast majority of git users tend to agree on one "origin" remote and 99-100% of their pushes and pulls are to/from that remote. So git, in practice, tends to be centralized when it comes time to collaborate with others. We're trying to re-decentralize that aspect while accommodating the convenient workflows we're all used to.

[+] X6S1x6Okd1st|6 years ago|reply
So Sia's Skynet is used for hosting the blobs and Tupelo is used for pointers to the blobs & metadata?
[+] fariel3456|6 years ago|reply
Looks like many commenters are clearly struggling with "decentralized like bitcoin" vs. "decentralized like git" distinction
[+] dejj|6 years ago|reply
What problem/threat is dgit meant to solve/guard against? Is it:

a) the people problem of coworkers not knowing the difference between a repository (e.g. on github), a remote (the name "origin") or even a branch (the label "master")

b) github.com turning evil or going away forever

c) myhost.example.com failing for hours or days

[+] jakear|6 years ago|reply
I don’t see any mention of issue/wiki support? Without that my GitHub workflow would be dramatically changed.
[+] cap10morgan|6 years ago|reply
Absolutely. Our strategy is to give you a decentralized on-ramp by starting with GitHub's central value proposition of the "one true git remote" that everyone can share. We made a GitHub action (https://github.com/quorumcontrol/dgit-github-action) to automatically mirror GitHub pushes on dgit so you can continue using GitHub's other tools (like issues and wikis) until dgit offers a compelling alternative for those.
[+] NickBusey|6 years ago|reply
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?
[+] zonotope|6 years ago|reply
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.
[+] stagas|6 years ago|reply
How do you maintain identity in dgit? i.e how do I claim my user/org name in this decentralized manner? It isn't clear how it works, can you elaborate on this part a little bit?
[+] zonotope|6 years ago|reply
Sure. First, a little background. The Tupelo distributed ledger manages repo identities and permissions, while Sia persists the actual git objects.

Tupelo validates transactions against individual ChainTrees, and you can think of a ChainTree as an independent ledger (or blockchain) that represents the state of one independent real world (or digital) object. In this case, that object is a git repository.

Tupelo only allows the "owner" of a ChainTree to make modifications to that ChainTree (such as updating the current HEAD), and ownership is determined by control of a private key.

Each ChainTree has a unique DID (decentralized identifier) that is uniquely determined by the key that first created it, and the controller of that key is the initial owner. Tupelo also has a transaction type that allows the current owner to transfer a ChainTree to a different key maintained by the new owner, but its DID stays the same after that transfer.

Tupelo uses a strategy similar to the WarpWallet[1] to manage identities. We can deterministically create a private key from a string like a repo name, and use that private key to create a ChainTree with a DID derived from that key (and hence, the DID is derived from the string). This gives us a mapping from repos to Tupelo ChainTrees. Since the initial "private" key is deterministically derived from the repo name, that initial private key is insecure. The second step of the repo registration process is to submit a ChainTree transaction to transfer ownership of the repo ChainTree to a secure private key. That way, only the controller of the secure private key can make changes to the repo ChainTree, even if anyone can reproduce the original key from the repo name.

[1]: https://keybase.io/warp/warp_1.0.9_SHA256_a2067491ab582bde77...

[+] victorheld|6 years ago|reply
You could just use pgp to sign your commits as a starting point
[+] theamk|6 years ago|reply
So who pays for this? It says it uses Sia as backend, but I know sia costs money. Is this currently being paid for by some org?
[+] nemetroid|6 years ago|reply
From a quick look, I believe "Dgit is a Git remote helper for decentralized [...]" would be a more accurate title.
[+] Etheryte|6 years ago|reply
The author has a very unique understanding of online security given the readme starts out with "just try it by running this unknown binary".
[+] andrewshadura|6 years ago|reply
A little disappointing they took the name already in use by another project. Dgit is a system exposing the Debian archive as Git, allowing to upload packages with a git push.