Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dgit: Git with decentralized remotes

github.com

Post reply on HN
Print view View original

61–70 of 87 posts

Re: Dgit: Git with decentralized remotes

#61

Post by nedbat »

pdonis wrote: post #35
zonotope wrote: post #26

Earlier quoted context omitted.

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.

Did you mean that Git's source code is open?

Re: Dgit: Git with decentralized remotes

#63

Post by unqueued »

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/

Re: Dgit: Git with decentralized remotes

#64

Post by bpw »

tylersmith wrote: post #36
kazinator wrote: post #34

Earlier 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.

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.

Re: Dgit: Git with decentralized remotes

#65

Post by hibbelig »

masukomi wrote: post #41
zonotope wrote: post #26

Earlier quoted context omitted.

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.

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?

I guess that the dgit remote URL specifies the sia network as a whole, without explicitly pointing to a specific node. When new nodes join, you don't have to change the URL of the remote.

But if you want to use normal remotes as a distributed network, and then a new node joins, you have to add a new remote with a new URL before you can use it.

Re: Dgit: Git with decentralized remotes

#66

Post by bpw »

ChristianBundy wrote: post #46
bpw wrote: post #30

Earlier quoted context omitted.

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…

> 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!

In the default setup, storage is provided by sia skynet, so on push all git objects are distributed across the sia network and are simply retrieved when you do a git fetch / clone from a dgit url. But as mentioned, thats configurable and could be any other storage system.

However, even with distributed storage, you still need to know what makes up the git index on a given git url (aka dgit://quorumcontrol/tupelo) - this is where the Tupelo DLT comes in. When you do a push, the Tupelo network verifies the request and updates the refs of that repo.

Both of these are just basic tcp/https requests, so there truly is no long running daemon on your machine required in order to push or fetch dgit repos.

Re: Dgit: Git with decentralized remotes

#67

Post by bpw »

ChristianBundy wrote: post #49
bpw wrote: post #30

Earlier quoted context omitted.

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…

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.

Well the basics underneath Tupelo are cryptographic signatures and an immutable chain we use call a ChainTree (which is per repo), so in theory this could work between two people so long as you trusted each other's signatures. Using the Tupelo network provides trust for the specific name, as well as prevents conflicting updates to the same repo.

It's a very interesting idea though, would love to hear more. Feel free to drop by our gitter: https://gitter.im/quorumcontrol-dgit/community

Re: Dgit: Git with decentralized remotes

#68

Post by Cyberdog »

bpw wrote: post #64
tylersmith wrote: post #36

Earlier quoted context omitted.

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…

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?

Re: Dgit: Git with decentralized remotes

#69

Post by asdkhadsj »

lucideer wrote: post #52
asdkhadsj wrote: post #48

Earlier quoted context omitted.

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/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, 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.

Post reply on HN