bpw

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

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.

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.

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!

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