
GitTorrent: A Decentralized GitHub (2015) - samatman
https://blog.printf.net/articles/2015/05/29/announcing-gittorrent-a-decentralized-github/
======
cjbprime
Hi! I started this project in 2015, using Bitcoin and BitTorrent -- since
then, I think Ethereum and IPFS have become better substrates for this sort of
work.

And, I think it remains the case that the difficult part of decentralizing
GitHub is not working out how to share repositories using p2p bandwidth, but
instead working out how to use p2p for the social features of the site, like
comments and pull requests.

Secure Scuttlebutt has some potential there, but as a gossip protocol it
doesn't have a way for people you don't know/follow to e.g. send you a PR.

~~~
cjslep
Gitea, Gogs, and Gitlab all have social-federation-related feature requests
open right now. Not sure where they will land, but some are mentioning
ActivityPub.

~~~
rapnie
Cool! That is really interesting. ActivityPub would be great for this. I've
added in links to the issues below:

Gitea:

\- [https://github.com/go-gitea/gitea/issues/1612](https://github.com/go-
gitea/gitea/issues/1612)

\- [https://github.com/go-gitea/gitea/issues/184](https://github.com/go-
gitea/gitea/issues/184)

Gogs:

\-
[https://github.com/gogs/gogs/issues/4437](https://github.com/gogs/gogs/issues/4437)

Gitlab:

\- [https://gitlab.com/gitlab-org/gitlab-
ce/issues/44486](https://gitlab.com/gitlab-org/gitlab-ce/issues/44486)

\- [https://gitlab.com/gitlab-org/gitlab-
ee/issues/4517](https://gitlab.com/gitlab-org/gitlab-ee/issues/4517)

edit: added gitlab enterprise link (plus formatting)

------
greyman
I would just like to mention, that in my opinion "decentralized GitHub" is an
oxymoron, Github's innate feature is being centralized, to centralize
developers into one place, being a kind of social network.

~~~
spinningarrow
But there are decentralised social networks (e.g. Mastodon). What are your
thoughts on those?

~~~
simplyinfinity
And who uses mastodon? I have never heard of a single friend even mention
mastodon. ever. Decentralised might be utopia for us, the hackers, the
techies... centralised however is for the masses. It's simply easier for them
to be where their friends are.

~~~
adyus
I don't remember where I first read it, but I liked this opinion: in the
future, decentralization, even if only adopted by a techie minority, will
serve as a threat of what could be, thus keeping the centralized powers in
check.

~~~
wslh
Full technical and governance decentralization is an utopia based on computer
science fundamentals. We need to start thinking about the constraints instead
of just jumping to the decentralization bandwagon as if was a matter of
choice.

------
Pengwin
Decentralised Centralised Decentralised Version Control System. What fun.

~~~
atomicnumber1
I think he's trying to decentralize the centralized part of git. Makes sense?

~~~
lucideer
There is no centralised part of git. He's trying to decentralise Git- _Hub_ ,
which is a centralised website that has many feautres, issues, projects, etc.
+ acts as a hosted Git remote.

Git != Github

~~~
zamalek
There is no _Hub_ in the article.

The problem with Git decentralization is that you need a publically accessible
endpoint (meaning there is an eventual central host). Even when you are using
email for patch files, your email becomes the central point of failure (even
if you host that yourself). So far as fetch goes, this is why git.kernel.org
exists.

Git behaves like an mp3-sharing website with multiple mirrors, where-as
gittorrent behaves like magnet URLs. This protocol effectively obsolesces the
requirement for remotes.

~~~
lucideer
> _There is no Hub in the article._

Not sure what you mean by this. The article mentions and compares itself to
Github throughout.

> _The problem with Git decentralization is that you need a publically
> accessible endpoint (meaning there is an eventual central host)._

I disagree slightly here. It's completely possible to build a network of
remotes that don't all reference a single central origin (e.g. teammates
referencing eachothers' local repos over authenticated connections, possible
on a LAN, etc.). This gets messy and is hard to administer securely, but Git
is more than capable. Also, the challenges of doing this Gittorrent securely
with private repos seem similar to those of using SSH remotes between
individual dev machines.

In terms of the article talking about "hubs" (Github specifically), Gittorrent
purports to replace the need for Github, but only fills one of the uses of a
hub. A hub like Github serves two purposes:

1\. a central origin, i.e. the same use git.kernel.org serves

2\. a searchable/discoverable network, e.g. the same use the central
thepiratebay.org search engine serves for Torrents. Decentralising this seems
like a hard problem.

------
swsieber
So, I think there's a couple relevant issues when talking about decentralizing
a github like service. There a couple of things Github provides, and my naive
approach to making GitHub less essential would be to address them one by one:

* Issue tracking. It's a bit hard to export these. I imagine it'd be a bit nicer to export if issues were actually stored inside git as trees. You could easily make the issues frontend use git as the storage backend. If users don't have an account, maybe they could issue a pull-request to the issue tracker?

* Notifications. This ones's a bit harder. Web-hooks?

* Merge requests - github uses refs internally (I think). That wouldn't be too hard to standardize. If somebody adds commits to their pull/merge request, then they just have to push the updated ref to the repo they're submitting to.

* Auth - this is hardest part. GitHub provides authentication & permissions for pushing. The issue with allowing merge requests submission from anybody (which you could do with a server side hook) is that now people can ddos you by submitting HUGE pull requests constantly. If you could make that safe, in theory you could get away without needing user account federation.

* There is also the big security issue that you can't actually use server side hooks for this stuff since libgit2 can be used to bypass it (when pushing using libgit2, it doesn't trigger server side hooks).

* Oh, and this entire time I've been thinking about the email & username as being unspoofable. But you can easily spoof them. I guess you need federated user accounts after all.

Edit: It's untrusted _interactions_ that's hard to decentralize
\---------------

All in all, I think that git is easily decentralized if you know you can trust
all the actors. It's untrusted git that's harder to decentralize.

~~~
chriswarbo
Regarding issues, the article mentions storing them in the repo using
BugsEverywhere. I use Artemis for this since it's simpler than BugsEverywhere.

I don't think "pull requests" are necessary for such a system. Even if you
like the pull request workflow (I personally find it tedious and cumbersome)
it can be achieved via existing mechanisms like personal email, mailing lists,
IRC, pastebin, etc. Trying to define one workflow and baking it into a
protocol sounds like a receipe for bloat. Note that git already has built-in
support for email.

Regarding authentication and permissions: I don't think git is any different
from other mutable collection of files in this regard. For example, I push my
git repos to IPFS just like any other files, and use IPNS to point at the
latest version. IPNS uses keypairs to limit access, which is a pretty standard
technology with known practices for things like revocation, indirection, etc.

Notifications are just another 'mutable collection of files', e.g. an RSS
feed, so solvable in the same way.

------
antocv
git-ssb is better than gittorrent, as bittorrent itself relies on a global
DHT, which can and has been censored.

~~~
cbenz
Some links:

git-ssb (Git over Secure-Scuttlebutt):

\-
[https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoy...](https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256)

\- [https://github.com/noffle/git-ssb-intro](https://github.com/noffle/git-
ssb-intro)

Secure Scuttlebutt
([https://www.scuttlebutt.nz/](https://www.scuttlebutt.nz/))

~~~
oelmekki
Thanks for sharing. I was discussing trackerless p2p social network with
offline publishing and syncing when close to a friend a few months ago, I'm
amazed how Scuttlebutt seems to be exactly that.

I was thinking of using high frequency sounds (inaudible) for peer discovery
when in the same room, like chromecast is doing when phone and chromecast are
not on the same local network, but simply scanning network seems to work just
as well, apparently.

------
vortico
What are the practical downfalls of this? Will my data be lost if the project
is not popular enough? Is it possible for peers to modify the repository? Can
I use access restrictions? I'm talking about the
`gittorrent://81e24205d4bac8496d3e13282c90ead5045f09ea/recursers` URLs, not
the GitHub based ones.

~~~
transfire
> Will my data be lost if the project is not popular enough?

I'd like to know how that works out too. I suppose in the end it's up to you
to make sure you keep a base copy of your project so it is always available,
even if near zero popularity.

~~~
cjbprime
I can think of a few interesting approaches:

1) We set up something like the Internet Archive, spidering and caching the
network, run using donated bandwidth. The hosting could be centralized like
the Archive or p2p itself (donated by peers).

2) A system like FileCoin's where you pay a tiny amount of money to ensure
other peers will always host your repos on the network.

3) A straight up centralized, for-profit service where you pay a company a
monthly fee to host your data on the network, as people already do with GitHub
itself.

~~~
fwip
Please note that FileCoin doesn't provide any guarantees. It only provides
incentives for other people to host your data.

It's like paying a centralized service, except you don't have any recourse
(legal or financial) if the people hosting it decide to stop.

~~~
cjbprime
Thanks for the correction. I guess you get a probabilistic "guarantee" in that
you could see how many peers are serving your content at any given time, and
make assumptions about their independence from each other and likelihood that
your content will stay available?

------
TekMol
What are the features that make GitHub? What if we used only git on the
command line?

Which features would we miss?

Maybe we could add those features with something similar to git, some
intelligent scripts?

~~~
Boulth
PRs and issues. PRs can be distributed using git appraise:
[https://github.com/google/git-appraise](https://github.com/google/git-
appraise)

~~~
euyyn
Also each user's "home page" of notifications. When I worked exclusively on
open-source projects, it became my daily "task list". It was very efficient to
have it all in that UI.

~~~
Boulth
I agree, notifications page is great, I also use it daily. Another thing is
profile page.

Maybe they could be solved in a federated way like Mastodon?

------
repolfx
A good way to implement this is with the Dat protocol:

[https://datproject.org/](https://datproject.org/)

They already have a competent P2P twitter clone, as an example app. If it can
do that it can probably do a github.

------
apichat
You should also look at [http://pijul.org](http://pijul.org)

------
theamk
I don't think this project should be git _torrent_ \-- after all, one of the
reasons bittorrent got so popular is non-distributed tracker and .torrent
files, which provide efficiency and authenticity.

Maybe git-donkey or git-gnutella instead?

------
ChankeyPathak
In case you're looking for alternatives, this thread might be of some help:
[https://news.ycombinator.com/item?id=17241487](https://news.ycombinator.com/item?id=17241487)

------
vhodges
SSB-Git

[https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoy...](https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256)

------
headgasket
I like the idea. I think it would be an interesting development to counter the
centralization in the big5. GitSpoke?

------
gcb0
what 'knows' the HEAD?

~~~
mwerty
I’m waiting for gitcoin.

~~~
shittyadmin
Freenet/Zeronet have updatable sites already, should be trivial to do with git
commits, grab the latest signed update based on this name and key hash...

Overall though I think a federated system that also handles issues is better,
something more akin to Fossil.

~~~
gboudrias
Fossil seems like one of many potential upgrades, and it's the second time I
hear about it today!

However I think the main problem is almost always existing users. Git has
arguably been falling behind in terms of features for quite a while now, but
its momentum makes it hard for a lot of devs (including me!) to switch to a
different vcs.

~~~
confounded
> _Git has arguably been falling behind in terms of features for quite a while
> now_

It’s all I’ve ever really used, and I’ve never seriously considered
alternatives. What features in other VCSs are interesting?

~~~
chriswarbo
Mercurial is very similar to git, but its CLI is considered to be easier than
gits (if potentially less powerful). Another difference is that mercurial
heavily discourages editing of history, which some git users seem to like
doing. Git is also faster than mercurial.

GNU arch was an early DVCS but didn't seem to gain much traction. It was
eventually superceded by Bazaar, which is much slower than git but was better
at tracking history e.g. across renames. I think git has improved in that
area, and bazaar has been getting less popular.

Fossil is built on an sqlite database and has a built-in Web UI and issue
tracker, which is fine for those who want that but violates the "do one thing"
principle (e.g. if you wanted to use some other issue tracker).

Darcs keeps track of patches and their dependencies, unlike git and mercurial
(which track snapshots and their diffs). This approach supposedly makes life
easier, and makes the darcs CLI quite usable. One problem is that some of the
merge algorithms can take an exponential amount of time to complete, which has
been getting addressed in recent years but many users seem to jump ship to
git.

Pijul is similar to darcs, but breaks compatibility in order to solve the
exponential merge problems. It looks very promising, but is still _very_ new.

------
miralabs
when ico?

------
developerdanny
This faux outrage at github being acquired by Microsoft is already boring.

~~~
babapapa
ya.. microsoft, the committed mortal enemy of Open Source Software, is now
holding the most important hub for Open Source Software.

~~~
jrs95
What year are you living in?

~~~
toofy
To paraphrase what someone else said yesterday:

In a world where companies are expected to have growth every quarter, a
project like GitHub is one bad quarter away from microsoft making major
changes or being abandoned or being completely shutdown.

As we’ve seen with product after product, when companies are expected to have
growth every quarter, they will sometimes (often?) make radical changes to the
software. In the case of GitHub, if microsoft decided it needed far more
profit coming in from GitHub, it is entirely reasonable to expect they may
decide to shift it into a service which is only usable for their large
corporate partners, or they may decide the social features need to go, or they
may decide to stop allowing public repos, etc...

Microsoft has shown many many times in the past that they’re more than willing
to throw out open standards and attempted to force adoption of their own
proprietary standards.

It is entirely reasonable to be at least a tad skeptical given their history
and their business model.

