5 ms·

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

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

brian_herman__ 7y ago
do you provide advantages to ssb?
- bpw 7y ago
  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 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 https://github.com/QuorumControl/tupelo-wasm-sdk) can run fully in the browser, meaning a fully decentralized UI is possible!
  - lucideer 7y ago
    > Using dgit doesn't require running a "node" of any kind (aka an SSB peer) Can you expand on this? An SSB "peer" is entirely local, so conceptually similar to a `.git` directory. I'm struggling to understand how a decentralised system can operate without peers. (I clicked through on the Tupelo link, but from what I can glean from the README, a Chain Tree sounds very similar to an SSB peer. Just trying to understand the distinction)
  - ChristianBundy 7y ago
    > 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!
    - bpw 7y ago
      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.
  - ChristianBundy 7y ago
    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.
    - bpw 7y ago
      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 https://gitter.im/quorumcontrol-dgit/community
pdonis 7y ago
> a decentralized git remote How is the git remote you provide "decentralized" as compared with the remote provided by GitHub?
- zonotope 7y ago
  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.
  - pdonis 7y ago
    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.
    - remram 7y ago
      GitHub is not open-source, though alternatives like GitLab and Gitea are.
    - BoorishBears 7y ago
      If you make your own GitHub "node", it won't have any of the information GitHub.com has. If I'm understanding correctly, the idea with this is every "node" has a portion of a canonical truth. Not sure that would still get people to use it, but at least more feasible than making your own GitHub instance in relation to growing network effect
    - nedbat 7y ago
      Did you mean that Git's source code is open?
  - masukomi 7y ago
    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?
lucideer 7y ago
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?
- asdkhadsj 7y ago
  I too am confused. My immediate thought was that Dgit offered a centralized remote, packaged around decentralized technology. Which is to say, many people have a main "master"; a single, centralized repo/branch. Dgit might be offering the same thing, but hosted in a decentralized fashion. I could see the value in this for backup, I suppose. Sure, Git is decentralized but many of us still prefer having some centralization. Bundling that up into a decentralized system (aka no third party host) has some value. Though really to me if I was avoiding Github/Gitlab/etc, the primary value add I'd want to see is all of the Github/Gitlab UI features. Notably pull requests, code reviews, comments, basic issue tracking, etc.
kazinator 7y ago
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.
- tylersmith 7y ago
  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.
  - kazinator 7y ago
    So "decentralized" is a synonym for "distributed"? Suppose I mount, under /path, some kind of distributed filesystem whose storage is replicated among many servers (for fault tolerance, availability, and performance) and then store a git repo into /path/to/repo.git. If I clone from this, so that my origin is "file:///path/to/repo.git", is that then a decentralized git remote?
  - Taek 7y ago
    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.
  - bpw 7y ago
    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.
Conan_Kudo 7y ago
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. :) [0]: https://pagure.io/pagure https://pagure.io/pagure

brian_herman__ 7y ago

do you provide advantages to ssb?

bpw 7y ago
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 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 https://github.com/QuorumControl/tupelo-wasm-sdk) can run fully in the browser, meaning a fully decentralized UI is possible!
- lucideer 7y ago
  > Using dgit doesn't require running a "node" of any kind (aka an SSB peer) Can you expand on this? An SSB "peer" is entirely local, so conceptually similar to a `.git` directory. I'm struggling to understand how a decentralised system can operate without peers. (I clicked through on the Tupelo link, but from what I can glean from the README, a Chain Tree sounds very similar to an SSB peer. Just trying to understand the distinction)
- ChristianBundy 7y ago
  > 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!
  - bpw 7y ago
    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.
- ChristianBundy 7y ago
  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.
  - bpw 7y ago
    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 https://gitter.im/quorumcontrol-dgit/community

pdonis 7y ago

> a decentralized git remote How is the git remote you provide "decentralized" as compared with the remote provided by GitHub?

zonotope 7y ago
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.
- pdonis 7y ago
  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.
  - remram 7y ago
    GitHub is not open-source, though alternatives like GitLab and Gitea are.
  - BoorishBears 7y ago
    If you make your own GitHub "node", it won't have any of the information GitHub.com has. If I'm understanding correctly, the idea with this is every "node" has a portion of a canonical truth. Not sure that would still get people to use it, but at least more feasible than making your own GitHub instance in relation to growing network effect
  - nedbat 7y ago
    Did you mean that Git's source code is open?
- masukomi 7y ago
  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?

lucideer 7y ago

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?

asdkhadsj 7y ago
I too am confused. My immediate thought was that Dgit offered a centralized remote, packaged around decentralized technology. Which is to say, many people have a main "master"; a single, centralized repo/branch. Dgit might be offering the same thing, but hosted in a decentralized fashion. I could see the value in this for backup, I suppose. Sure, Git is decentralized but many of us still prefer having some centralization. Bundling that up into a decentralized system (aka no third party host) has some value. Though really to me if I was avoiding Github/Gitlab/etc, the primary value add I'd want to see is all of the Github/Gitlab UI features. Notably pull requests, code reviews, comments, basic issue tracking, etc.

kazinator 7y ago

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.

tylersmith 7y ago
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.
- kazinator 7y ago
  So "decentralized" is a synonym for "distributed"? Suppose I mount, under /path, some kind of distributed filesystem whose storage is replicated among many servers (for fault tolerance, availability, and performance) and then store a git repo into /path/to/repo.git. If I clone from this, so that my origin is "file:///path/to/repo.git", is that then a decentralized git remote?
- Taek 7y ago
  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.
- bpw 7y ago
  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.

Conan_Kudo 7y ago

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. :) [0]: https://pagure.io/pagure https://pagure.io/pagure