Live data from Hacker News

Dgit: Git with decentralized remotes

github.com

71–80 of 87 posts

Re: Dgit: Git with decentralized remotes

#72
post #64

Earlier quoted context omitted.

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…

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?

It is free for the time being. But you point out a good reason why we built dgit to support other storage backends.

Re: Dgit: Git with decentralized remotes

#74
post #50

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 a…

So, two things I see here, 1) only one person is allowed to push changes to the dgit repo then? How are you supposed to collaborate on a remote dgit repo, in that manner it is very different than a github remote, or am I missing something? and 2) Someone can hoard all popular repos and make it seem that they are original versions, pointing people to clone them from dgit, when in fact they could have been modified with malicious code? How do you address these issues?

Re: Dgit: Git with decentralized remotes

#75

Earlier quoted context omitted.

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/i…

> 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,…

> hosted on a decentralized platform (IPFS)

What's the difference between this kind of "decentralized platform" and GitHub?

Re: Dgit: Git with decentralized remotes

#76
post #73
post #62

Earlier quoted context omitted.

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.

Eventually everything will be of, by and for the github so you're probably fine.

Re: Dgit: Git with decentralized remotes

#77
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

Re: Dgit: Git with decentralized remotes

#78
post #75

Earlier quoted context omitted.

> 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,…

> hosted on a decentralized platform (IPFS) What's the difference between this kind of "decentralized platform" and GitHub?

There was that thing a few months* back about Iranian software devs losing GitHub access due to the newer sanctions.

Presumably if you were to host on IPFS it would be more difficult for people to cut you off like that.

What's the practical difference between you pinning your own IPFS node and just self hosting? Pass.

* Years? Time is weird at the moment.

Re: Dgit: Git with decentralized remotes

#79
post #75

Earlier quoted context omitted.

> 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,…

> hosted on a decentralized platform (IPFS) What's the difference between this kind of "decentralized platform" and GitHub?

Theoretically the difference is that it is.. well, distributed. Aka any benefits you'd attribute to having a file on IPFS over Github could apply here.

Which is to say, if Github goes down, gets blocked, blocks your team, etc; your team can still push to the "centralized" repo, etc etc.

Re: Dgit: Git with decentralized remotes

#80
post #75

Earlier quoted context omitted.

> hosted on a decentralized platform (IPFS) What's the difference between this kind of "decentralized platform" and GitHub?

Theoretically the difference is that it is.. well, distributed. Aka any benefits you'd attribute to having a file on IPFS over Github could apply here. Which is to say, if Github goes down, gets blocked, blocks your team, etc; your team can still push to the "centralized" repo, etc etc.

> if Github goes down, gets blocked, blocks your team, etc; your team can still push to the "centralized" repo, etc etc.

But as others have pointed out, I can set up such a backup anywhere. What is the advantage of this particular way of doing it?

Post reply on HN