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?
You could just use pgp to sign your commits as a starting point
Dgit: Git with decentralized remotes
51–60 of 87 posts
Re: Dgit: Git with decentralized remotes
#52Earlier quoted context omitted.
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/mountRe: Dgit: Git with decentralized remotes
#53So Sia's Skynet is used for hosting the blobs and Tupelo is used for pointers to the blobs & metadata?
Re: Dgit: Git with decentralized remotes
#54As 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…
You might want to consider collaborating on building out Pagure[0], which is a git forge that enables decentralized development.
Pagure supports submitting pull requests with Git repos on any server (regardless of whether it's running Pagure or not) with its remote pull requests feature. Issues, docs, and pull request metadata are all stored as git repos using JSON files as data, making it easy and portable to other Pagure instances and easy to convert for any other system. This makes it an excellent base for building decentralized development workflows with the oft-expected Git forge interface model. Since all the stuff is in Git repos, they could all be backed by dgit, for example. :)
Re: Dgit: Git with decentralized remotes
#55A thread from 2016: https://news.ycombinator.com/item?id=11430009
I think that's a different dgit
Tacking on to this subthread: another "dgit" that i'm familiar with is https://wiki.debian.org/DgitFAQ
Re: Dgit: Git with decentralized remotes
#56So Sia's Skynet is used for hosting the blobs and Tupelo is used for pointers to the blobs & metadata?
Exactly
Re: Dgit: Git with decentralized remotes
#57The author has a very unique understanding of online security given the readme starts out with "just try it by running this unknown binary".
Re: Dgit: Git with decentralized remotes
#58Re: Dgit: Git with decentralized remotes
#59How 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...
Re: Dgit: Git with decentralized remotes
#60Earlier quoted context omitted.
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.
In most contexts, "IPFS" really just means "self-hosted", because it only works if someone who actually cares about the file (in practice, just the author typically) is seeding it.
For Sia/Skynet, the Sia network is doing the hosting, meaning the file has high uptime even if the uploader does not, and even if nobody else chooses to pin/seed the file.