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.

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.

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.

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

Thanks for the info.

Is there a simple way right now to use another storage backend than Sia? E.g. If I have a group of people that want to participate in hosting, but only want to host data from the people in the group?

Essentially, can you use dgit to store a repo decentralised without having to set up git synchronisation tools, but while still having control over the hosting infrastructure?

hey cfstras, another dgit dev here. Each repo has a storage adapter specified, so any storage infrastructure is possible, but at this moment we've only written two: sia and on tupelo network.

We've had a lot of experience with running IPFS nodes internally, that might be a great option for you in this case? We are in early stages and will add more adapters as feedback informs.

Also, its open source and we would love PRs :) - the storage interface is pretty straight forward:

https://github.com/go-git/go-git/blob/master/storage/storer....

Here is an example within dgit: https://github.com/quorumcontrol/dgit/blob/master/storage/ch...

What makes Skynet more decentralized than GitHub? Guess I'm confused.

I don’t see any mention of issue/wiki support? Without that my GitHub workflow would be dramatically changed.

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.

Shameless plug regarding the issues: https://github.com/MichaelMure/git-bug

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.

Our setup process is a much lighter lift than standing up a server and installing gitolite on it.

I think a counter to that is only one person needs to set up the additional git remote, compared to everyone having to install additional software to use dgit.

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 GitHub's other features until we build more decentralized alternatives

do you provide advantages to ssb?

dgit dev here: first, let me say git-ssb is a great project as well!

We see a few distinct advantages:

- Using dgit doesn't require running a "node" of any kind (aka an SSB peer). This is possible because of the unique architecture of the Tupelo DLT: https://github.com/quorumcontrol/tupelo.

- Because of ^, installing and adding a dgit remote to your existing workflow is super easy.

- The storage in dgit is separated from the ownership of the repo. This means you can distribute the actual git objects across any storage system you would like, see my comment to cfstras below.

ssb is a few years ahead here - having a web ui and more robust suite of collaboration tools is great, but we're hoping to add those features down the road as well! Another unique advantage is the Tupelo js client (https://github.com/QuorumControl/tupelo-wasm-sdk) can run fully in the browser, meaning a fully decentralized UI is possible!

Using dgit doesn't require running a "node" of any kind (aka an SSB peer)

I'm not sure that I understand this, could you add details? The only interpreteation that makes sense is "you don't have to run any software on your computer", but that would suggest that the storage is centralized on some internet services.

Happy to chat about SSB any time. Good luck on this project!

Also: Does this work offline, or on just a LAN? To be completely candid, I feel very strongly that we should be moving away from decentralized protocol that require anything more than two friends and a wifi network.

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.

anyone who is running git is _already_ running a distributed git node which is not managed by a single central entity.

there are many _many_ web based git apps (many of which provide github like features) that anyone can, in theory, set up.

why would I want to set up a sia node instead?

Perhaps the Sia node gives you access to a "master" repo. Aka a single entity that represents a centralized repo, but hosted on a decentralized system.

Not sure though.

There's no such thing as a "master" repo in Git. "origin" is the default name for a cloned remote, and the convention used for adding a default remote, but nothing distinguishes the origin remote from any other remote. It isn't a master remote other than being default.

One could add a Git remote (and name it "origin") that's backed by a decentralised system currently: e.g. one could do:

  git remote add origin ./some/ipfs/mount

There's no such thing as a "master" repo in Git. "origin" is the default name for a cloned remote, and the convention used for adding a default remote, but nothing distinguishes the origin remote from any other remote. It isn't a master remote other than being default.

You're over thinking my example. As I said, by "master" repo I meant the centralized repo that many _(most?)_ git users have, somewhere. Aka Github, Gitlab, etc.

You're conflating Git's design with users patterns of centralization and distributed teams. Notably that often there is a single, centralized branch(es) on a single repo that everyone merges to.

This centralization could be distributed. It sounds trippy, but as you put it if your origin is on IPFS, you effectively have a single, mutable repo instance hosted on a decentralized platform (IPFS).

My guess is that is what Dgit is. A single mutable instance, hosted on a decentralized platform (Sia).

So back to my example, many people do indeed have a "master"/centralized repo. It's not a part of git, it's a user convention on top of git. But I didn't say it was in git.

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.

love the discussion here - I'ld like to provide a bit of clarity on the architecture for context.

The `dgit://` protocol that gets registered with the `git-remote-dgit` helper is not in itself a remote resource, but rather a deterministic identity that has been registered with the Tupelo DLT (zonotope provided good details on this below). Therefore the ownership as well as the current state (branches, tags, maybe PRs in the future :), etc) of the remote repo is decentralized away from a single entity (aka GitHub/GitLab) - as the owner, you fully control it, nobody else can modify it - not even the dgit team.

The storage part of your dgit remote is much more on the "distributed" side. We chose sia's skynet because we think it's a great fit for this. However, the actual objects of the repo could be stored anywhere, S3, IPFS, exchanged over bittorrent, or even your local raspberry pi. Regardless of where the git objects live, there still remains a single, trusted, distributed index of your repository on the Tupelo DLT.

It costs "money" (Siacoin tokens) to store data on Sia IIRC, but I don't see any mention on the GitHub repo or elsewhere in this thread about having to pay anything to use this. Is Skynet effectively free?

While I know there are many devs out there who confuse & conflate "Git" and "Github" and don't really know the difference between the two, I don't think bringing the conflation into "informed" discussion is particularly helpful.

Conceptually, Github is not different for the local ".git" folder sitting on my machine. I can do `git clone '../some/local/dir/.git" just as easily as I can with any SSH or HTTPS link: the underlying protocol used for the transaction changes but the concept does not. So I think defining a "remote" as something inherently centralised by definition just because Github et al are popular isn't helpful: it simply persists the misconception.

Basically: I'm still actually struggling to really fully understand what dgit is.

git-ssb is a protocol for accessing git repos stored in an ssb-db (which is a distributed db). git-ssb-web is a web UI for exposing git repositories stored in an ssb-db.

Can you explain dgit in those terms?

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?

A thread from 2016: https://news.ycombinator.com/item?id=11430009

I think that's a different dgit

Two different dgits from github? wow!

the previous one is from github, the new one is hosted on github but not from github.

I obviously needed to read this more closely.

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.

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

So Sia's Skynet is used for hosting the blobs and Tupelo is used for pointers to the blobs & metadata?