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
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.
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".
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.
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.
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.
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?
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.
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.
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.
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")
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.
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.
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?
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.
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.
[+] [-] lucideer|6 years ago|reply
For a similar project, see git-ssb https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoy...
[+] [-] zonotope|6 years ago|reply
[+] [-] jedimastert|6 years ago|reply
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
[+] [-] Tyr42|6 years ago|reply
[+] [-] tylersmith|6 years ago|reply
[+] [-] kyberias|6 years ago|reply
[+] [-] unqueued|6 years ago|reply
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
[+] [-] cap10morgan|6 years ago|reply
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
[+] [-] oefrha|6 years ago|reply
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
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.
[+] [-] michaelmure|6 years ago|reply
[+] [-] dang|6 years ago|reply
[+] [-] coderzach|6 years ago|reply
[+] [-] X6S1x6Okd1st|6 years ago|reply
[+] [-] zonotope|6 years ago|reply
[+] [-] fariel3456|6 years ago|reply
[+] [-] dejj|6 years ago|reply
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
[+] [-] cap10morgan|6 years ago|reply
[+] [-] NickBusey|6 years ago|reply
[+] [-] zonotope|6 years ago|reply
[+] [-] stagas|6 years ago|reply
[+] [-] zonotope|6 years ago|reply
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
[+] [-] theamk|6 years ago|reply
[+] [-] nemetroid|6 years ago|reply
[+] [-] Etheryte|6 years ago|reply
[+] [-] andrewshadura|6 years ago|reply
[+] [-] nottorp|6 years ago|reply
[deleted]