
GitTorrent: A Decentralized GitHub - luu
http://blog.printf.net/articles/2015/05/29/announcing-gittorrent-a-decentralized-github/
======
rektide
Lovely work!

 _We ask for the commit we want and connect to a node with BitTorrent, but
once connected we conduct this Smart Protocol negotiation in an overlay
connection on top of the BitTorrent wire protocol, in what’s called a
BitTorrent Extension. Then the remote node makes us a packfile and tells us
the hash of that packfile, and then we start downloading that packfile from it
and any other nodes who are seeding it using Standard BitTorrent._

The disadvantage here is that any given file in the repo could be stored in an
ever increasing number of packfiles. Each existing version of the repo will
generate a new packfile to get it to the newest version, and it's up to the
authenticated masters to generate and seed each of those packfiles, while
peers either do or do not cache these replicated datas. In short, this means
of syndicating updates ignores the Merkle-DAG-ness (DAG-osity?) of Git.

The un-updateability of torrents is something that seems to seriously limit
it's use. There are a lot of interesting attempts to hack around this-
LiveStreaming and Nightweb are two that spring to mind.
[https://www.tribler.org/StreamingExperiment/](https://www.tribler.org/StreamingExperiment/)
[https://sekao.net/nightweb/protocol.html](https://sekao.net/nightweb/protocol.html)

~~~
ChuckMcM
I agree it is really stellar. The billion dollar concept for me though is
encrypted repo torrents. Imagine a group of servers that are hosting encrypted
chunks which form the basis of a homomorphic encryption protocol for
distribution using forward error correction to allow recovery of the deltas if
n of m components of that delta can be recovered. Basically if you have the
key you can pull out of this amorphous cloud your source code, and if you
don't have the key you won't even know it is out there.

I started building a toy version of this about 5 years ago but got distracted
by work. Essentially the repo key encrypted the packfile, the storage
reliability layer used its another key to encrypt the chunks. The latter key
would find the chunks, with enough reliability to re-create the encrypted
packfile, which the latter key could decrypt and apply to your repo.

A very fun problem in distributed systems and data structures.

~~~
TimJRobinson
I've always thought this would be amazing for file storage in general. A
Dropbox that just syncs with the cloud encrypting your content with a private
key and you can withdraw it at any time. You simply give back say 5 x as much
storage as you use for the data mirroring.

~~~
m_mueller
AFAIK this was the concept behind Wuala. Founded in Switzerland, later bought
by French company LaCie. According to their website the clien side encryption
is still there, however they discontinued the collaborative disk space
business model.

~~~
ianopolous
We're trying to recreate that concept with peergos,
[https://github.com/ianopolous/Peergos](https://github.com/ianopolous/Peergos)
we're considering trying to use ipfs, [http://ipfs.io](http://ipfs.io) under
the hood which would be nice. Wuala was great but they never open sourced it
and stopped the storage earning in 2008.

------
ArneBab
> It surprised me that nothing like this seems to exist already in the
> decentralization community.

There was a GSoC project in 2013 which did exactly this, using Freenet as
decentralized storage backend with a Web of Trust for Spam resistant and
updatable identities (note that in the gittorrent scheme once someone claimed
a username, that username will stick there forever). It works and compared to
GitTorrent it adds anonymity and upload-and-run.

A current article describing it is here:
[http://draketo.de/english/freenet/real-life-
infocalypse](http://draketo.de/english/freenet/real-life-infocalypse) (it got
referenced here, too:
[https://news.ycombinator.com/item?id=9562749](https://news.ycombinator.com/item?id=9562749)
)

The GSoC project was done by Steve Dougherty: [http://www.google-
melange.com/gsoc/project/details/google/gs...](http://www.google-
melange.com/gsoc/project/details/google/gsoc2013/sdough/5650716672655360)

> I’d be happy to work on a project like this and make GitTorrent sit on top
> of it, so please let me know if you’re interested in helping with that.

Have a look at Gitocalypse:
[https://github.com/SeekingFor/gitocalypse](https://github.com/SeekingFor/gitocalypse)

------
arxpoetica
Major fan of this idea. But how does one address the GUI challenges presented
by leaving GitHub behind? It can't be understated that GitHub provides an
amazing (communal/social) user experience.

~~~
cjbprime
(Author here.)

You're right, of course. This is just a first step.

One interesting followup idea might be that the BitTorrent library I'm using,
webtorrent, also works in browsers over WebRTC. But I'm not using that because
I wouldn't know what to do with a git cloned repo inside of a browser tab.
Maybe someone else will though. :)

~~~
yazaddaruvala
GitHub provides: - Repo hosting, - Search, - Community

In comparison to decentralized Search and Community, decentralized file
storage is easy. Conveniently, centralized repo hosting is the biggest
problem. Not being able to Search / Comment / Report a bug during a DDOS
decreases productivity, but not being able to push commits / run CI tools is a
productivity halt.

The best next move, might be to focus on decentralized repository hosting,
solve that well, and allow users to conveniently mirror the GitTorrent repos
on GitHub. Giving the best of both worlds until Search and Community can also
be solved well.

This may mean GitTorrent would need some form of post push hooks (i.e. to
update mirrors or run CI). Which I'm sure is doable.

~~~
wfn
Hmm, decentralized search here should probably just use a Kademlia-like
implementation
([http://en.wikipedia.org/wiki/Kademlia](http://en.wikipedia.org/wiki/Kademlia))
where a 'XOR metric' is used to measure distance between nodes. (That way the
max number of lookups will be log2(n) where n is the number of nodes (with
further optimizations possible))

Obviously someone would need to build a user-friendly interface for all that,
etc.

------
shea256
Love this.

The post mentions using the blockchain for unique username registration and
mapping to public key hashes, and as it turns out there's a project I and
others have been working on that does exactly this called Blockstore.

Here's the link if anyone wants to check it out:
[https://github.com/namesystem/blockstore](https://github.com/namesystem/blockstore)

The way it works is there's a mapping between a unique name and a hash in the
blockchain, and then there's a mapping in a DHT from the hash to the data to
be associated (which can be a plain old public key and can also be a JSON file
that references a public key and other identity information).

~~~
cjbprime
(GitTorrent author here.)

That's great, thanks! I should just use this (preferably with the DHT I'm
already using to look up Git commits) instead of reimplementing myself.

What do you think about the idea of making pluggable modules to connect
Blockstore with web frameworks (Django, Rails), without the framework/website
authors having to get involved in understanding Bitcoin themselves?

~~~
shea256
Oh I love that idea.

As far as Django, Blockstore is on Pypi so you can just install and import the
library.

I think it'd be great to have modules for Rails, Node, etc.

I saw your tweet and I'll shoot you an email. Also feel free to open an issue
on github.com/namesystem/blockstore and we can discuss the idea openly there.

------
dmarti
The remaining hard part is the adapter layer to enable the extra applications
such as the issue tracker to use the Git repository for storage. Joey Hess has
a good article about Git "databranches" here:
[https://joeyh.name/blog/entry/databranches/](https://joeyh.name/blog/entry/databranches/)

------
ackalker
A very interesting idea, GitTorrent, but I have one question which comes to me
whenever I read about a delta-based distribution scheme: who is going to
generate and share all those deltas?

Some Linux distributions have experimented with delta-based package
repositories, examples are deltup for Arch Linux and rpm-delta for RPM-based
distros. Some of the known issues are:

\- choosing the number and spacing between deltas. Fine-grained deltas require
more storage space, coarse-grained deltas require more download bandwidth.

\- retiring old deltas: periodically deleting all deltas older than a certain
version, replacing them with the full package of that version. Again a trade-
off between storage space and download bandwidth.

For Git repositories, this would roughly translate to:

\- choosing the number, history spacing, and size of the Git packs per
repository.

\- retiring old Git packs: periodically deleting Git packs older than a
particular revision, replacing them with a bare repository at that revision.

~~~
pjc50
Git is _built out of_ deltas. You're already storing all of them.

~~~
peterwaller
This is isn't quite how I would describe it. Git does do delta compression in
packfiles, but the fundamental primitives lack deltas. It's just:

* The contents of this directory is this list of of files whose contents have these SHAs.

This is called a "tree".

The SHA of a tree is also an object, and can appear in another tree.

To see this for yourself, in any git repository run `git cat-file -p HEAD`.
You'll see the (more or less) raw commit object for HEAD, which will point at
a tree SHA. To see the contents of that tree-sha, run `git cat-file -p <the
tree SHA>`. That tree object has a one-to-one correspondence with what you'll
see on-disk in the objects directory, (if the object has not been put in a
pack file).

Above I have more or less fully described the contents of the files found in
`.git/objects`.

The delta'ing doesn't happen until later, if and when packfiles are
constructed. But they're just a storage/bandwidth optimisation. AFAICT, these
deltas have nothing to do with what you might think of as "git diff", which is
just some fancy porcelain which looks at objects.

The nice property of the construction is that given a large tree, even if
nested, if you change a single file in that tree, you will only change as many
trees as the file is deep in the tree, so computing changes between two nearby
trees can usually be done quickly.

------
shmerl
_> There are philosophical reasons, too: GitHub is closed source, so we can’t
make it better ourselves._

There is GitLab.

~~~
sytse
GitLab CEO here, thanks for mentioning us as the open source alternative. We
think in the short term multiple organizations hosting their own GitLab is the
way to go. It is hard to do issues and pull/merge requests in a decentralized
way (the OP is impressive but it shows distributed git instead of distributed
GitHub). I would like to see federated merge requests
[http://feedback.gitlab.com/forums/176466-general/suggestions...](http://feedback.gitlab.com/forums/176466-general/suggestions/5097708-implement-
cross-server-federated-merge-requests)

~~~
js2
_It is hard to do issues and pull /merge requests in a decentralized way_

...Over the web...

I mean, Git and Linux are developed via email lists, which is a decentralized
way of sending pull/merge requests, isn't it? I guess you could argue the
mailing list is hosted on a server, fine. So then fine, usenet.

Yeah, email and nntp are old crufty technologies and there are obviously
advantages to having a web based interface and a central place to go for a
project. But git itself certainly supports a decentralized mechanism for
merging.

So then the question really is, how do you decentralize a web interface, isn't
it? The dvcs itself isn't the problem.

~~~
doragcoder
Wouldn't a decentralized web interface be webmail (i.e. Gmail)? Then along the
Gmail theme, a plug in could make things look much like a static website.
Where "conversation view" becomes a "repository view".

~~~
nicky0
There's nothing decentralised about Gmail.

------
alganet
I'd love something like this for fossil[1], which can also handle wiki and
issues inside it's repos by default.

[1]: [http://fossil-
scm.org/index.html/doc/trunk/www/index.wiki](http://fossil-
scm.org/index.html/doc/trunk/www/index.wiki)

------
doragcoder
I need to go more in-depth on the proposal. But the first thing that strikes
me, is if you're going to use the Blockchain (with a capital "B") as storage
of usernames and such. Why not use namecoin? It has the process for name
consensus down. Also it won't pollute the main Bitcoin blockchain.

~~~
cjbprime
Hi, author here.

I have a mild bias against altcoins, and have heard bad things about Namecoin
in particular: that the anti-spam incentives aren't good, leading to illegal
files stored in the blockchain itself, and that there's no compact
representation (like Bitcoin's Simplified Payment Verification) for
determining whether a claimed name is valid without consulting a full history.

As I understand it, these two design flaws combine to mean that you have to
store some very illegal files to use a namecoin resolver, which doesn't sound
good to me. (I may be mistaken, since the bad things I heard about Namecoin
came from Bitcoin people..)

~~~
jMyles
The notion that a file can be illegal makes as much sense to the internet as a
plant being illegal makes to the earth.

Especially when it has the side effect of inhibiting what otherwise might be a
compelling solution.

~~~
cxxv
Your analogy doesn't hold up, as (for one) we have society and plants don't.
I'm glad that child porn is illegal (which is usually distributed in files),
as it makes the world safer for children.

Also: some plants are serious jerks.

~~~
nilved
If pi goes on forever, it contains any and all representations of child porn
that could exist. The first person to calculate pi that far will be breaking
the law. No, that doesn't make sense, nor does any sort of information being
illegal. What does make sense is to legislate the actions that can generate
that data, or the misappropriation of that data.

~~~
StephenFalken
Great point !

~~~
yoplait_
no, it's a really contrived point.

------
k2enemy
Forgive me if my comment too readily reveals my ignorance on these topics, but
would the IPFS project [0] be useful for this?

[0] [http://ipfs.io](http://ipfs.io)

~~~
tperson
Definitely, checkout their example on how to host git on ipfs[0]

[0]
[http://gateway.ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsN...](http://gateway.ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/example#/ipfs/QmThrNbvLj7afQZhxH72m5Nn1qiVn3eMKWFYV49Zp2mv9B/git/readme.md)

~~~
e12e
While integration between git and ipfs is good -- I'm not sure I see how this
is much different from just tar-ing up a git-archive and creating a
torrent/magnet (setting aside many of the other aspects of how ipfs and
torrents work).

Decentralized git pull for only a given hash isn't all that interesting?

If one could pull in updates and/or push changes -- that would be
"decentralized git". This is example is more "ipfs.io as a transport for git-
releases", rather than "ipfs.io as a transport for git"?

------
innovator116
Similar to Gitchain [http://gitchain.org/](http://gitchain.org/) ?

~~~
cjbprime
(Author here.)

Yeah! I was a Gitchain backer. The difference is that Gitchain stored the
actual git commits in the blockchain, and I leave the actual commits on the
hard disks of each BitTorrent seeder.

------
alexnewman
Stored github in btsync for a startup before. It actually worked ok. We
stopped doing it because btsync was trivial to crash with basic fuzzing and
was closed source

------
physcab
This is an aside but I like the author's writing style. Not only is he clear
but also describes why he's doing what he's doing and how it's important to
him and others. Really helps me give the ideas more thought!

------
durin42
> Google Code announced its shutdown a few months ago, and their rationale was
> explicitly along the lines of “everyone’s using GitHub anyway, so we don’t
> need to exist anymore”.

I mean, sorta. It was also because running a service is expensive, and
containing abuse is a constant thankless treadmill.

> We’re quickly heading towards a single central service for all of the
> world’s source code.

Far from it? Not that a fully-decentralized system seems bad, but there are
many things that aren't github. I don't even have anything of interest on
github.

------
mrisse
Can I clone GitTorrent with GitTorrent?

~~~
cjbprime
Yes, it works.

npm install gittorrent

git clone gittorrent://github.com/cjb/gittorrent

Or for true decentralization (doesn't get the wanted sha1 from github.com):

gittorrent://81e24205d4bac8496d3e13282c90ead5045f09ea/gittorrent

~~~
colund
I got fatal: Unable to find remote helper for 'gittorrent'

~~~
cjbprime
How about "sudo npm install -g gittorrent"? It looks like the git-remote-
gittorrent binary isn't ending up in your $PATH.

~~~
viraptor
Or without polluting global namespace:

export PATH="$PATH:$HOME/node_modules/.bin"

------
ianphughes
I have to admit that I started reading this post feeling a little snarky about
the concept. However, I think Chris makes an excellent case for the concept.

------
tr4s
How is the new value for a mutable key propagated through the DHT? (as in how
sure am I to get the newest commit hash?)

------
decentrality
This is awesome, but it centralizes on JavaScript.

It is an implementation of a standard without the standard being defined so
other implementations can spring up.

Git, one could argue, is language centralized also, which is technically true.
That I don't have an answer for. But I don't believe handing off so much
dependence to a JavaScript application fits for me.

A C/C++ application like Git I can overlook, at least for a decade or so, but
JavaScript feels like a perpetual beta/prototype only. Granted, that's my
subjective feeling.

Raised issue:
[https://github.com/cjb/GitTorrent/issues/12](https://github.com/cjb/GitTorrent/issues/12)

~~~
swombat
The word "centralize" in the way you're using it is very misleading. Every
piece of programming in existence uses some sort of language.

What you're really stating, I think, is that this is written in Javascript and
you don't like Javascript. That's totally fine, and it's your prerogative. I'm
sure that, like any other piece of programming, GitTorrent can be rewritten in
other languages. If Javascript bothers you that much, then do this: rewrite it
in Ruby if that's what you prefer.

But please stop attacking the claim that this is "decentralised github" by
claiming that this "centralises" on Javascript. It doesn't "centralise" on any
language. It's just a first implementation written in Javascript.

~~~
decentrality
That this implementation being uncomfortable for me is my subjective feeling,
I've mentioned several times. That I don't want to depend on JavaScript is
clear. I don't want to depend on JavaScript. Using the word centralize the way
I have, I can't see otherwise. But I'm not defaming anyone. I'm not attacking
anything. I'm very motivated to help the standard advance, but I would never
for a moment install this implementation. Stupid of me? Sure, maybe. But it's
not an attack.

What I wanted I already got, confirmation by the OP that this is in fact a
reference implementation and not the all-end-all.

Were that clear to start with, I wouldn't have commented other than to say,
awesome! This is extremely exciting to me.

------
Skunkleton
I could see this integrating really nicely with mailing lists. The commit
could be sent out to the mailing list, and anyone who is interested in
reviewing the code or doing a merge would already have the information they
need, no blockchain required.

------
comex
If a version of this with friendly name support is released, I will mirror all
my active GitHub repositories there.

If someone builds on this, as discussed elsewhere in the thread, to make a
decentralized service that mimics 'social' functionality such as issues and
pull requests, I will strongly consider using it instead of GitHub (depending
on the UI, stability, etc.).

I don't even have any particularly popular repos, so there is no real reason
for anyone to care about the above, but, y'know, HN comments approving of the
idea don't necessarily translate into actual interest in the product, so now
you know there's at least one person in the latter category. :)

------
z3t4
I always thought Github was open source and that you could fork it, like in
the spirit of Github. I find that slightly ironic =)

What's stopping a decentralized github from ending up in the same fate as the
newsgroups, that the data set gets too large to handle !?

I think that Github is more then just a repository, it's a community. I kinda
quit Facebook and signed up to Github instead :P And if it weren't for Github
I would have never touched git.

Startup idea: Create something like Github and assembly.com, but with a
complete tool-set (git+vps)

------
hellbanner
Well done.

I think this is a great piece to build a "pay for branch merging" way of
promoting open source.. use decentralized currency and voila, automated
programming.

------
pdudits
What I miss in the article or discussion is consistency of refs. The moment
your remote is a distributed one, it may have two different values for HEAD in
single point of time in different parts of network. If two clients push in
this time, HEADs diverge even further.

So as in distributed databases, you either:

* need to acquire exclusive lock on the repository metadata, or

* accept, that your push will be eventually discarded because you did not have up to date metadata

------
kodisha
decentralized web interface? Isn it better to develop native, cross platform
app for that?

We have both electron and NW.js now, that should be easy.

------
hobarrera
I like the idea of decentralized, but I'm not sure we need p2p as well.

It'd be interesting to see something like gitlab to have some sort of
federation support; where multiple instances can talk to one another ( _a la
xmpp /smtp_), so as to clone/send pull-requests, etc across different
instances.

~~~
sytse
We would love to see features like that in GitLab
[http://feedback.gitlab.com/forums/176466-general/suggestions...](http://feedback.gitlab.com/forums/176466-general/suggestions/5097708-implement-
cross-server-federated-merge-requests)

------
4684499
I don't think this is new.
[http://code.google.com/p/gittorrent/](http://code.google.com/p/gittorrent/)

------
laumars
I don't understand why so many people are in awe of this project when it seems
to be based on a number of falsehoods:

 _> "imagine someone arguing that we can do without BitTorrent because we have
FTP. We would not advocate replacing BitTorrent with FTP, and the suggestion
doesn’t even make sense! First — there’s no index of which hosts have which
files in FTP, so we wouldn’t know where to look for anything."_

Actually there is. It's called a mirror list. Most FTP-based repositories
support this.

 _> "And second — even if we knew who owned copies of the file we wanted,
those computers aren’t going to be running an anonymous FTP server."_

Except bittorrent does turn your client into a server. Many clients silently
punch holes in your firewall via uPnP, so you don't always realise you're
running a server, but it does still happen.

And as for anonymous FTP servers, it depends on what you mean there. If you
mean anonymous access, then that's not only supported, but actually the norm.
If you mean the server itself is anonymous, then it should be noted that
neither github nor torrent seeding peers are anonymous either.

 _> "Just like Git, FTP doesn’t turn clients into servers in the way that a
peer-to-peer protocol does. So that’s why Git isn’t already the decentralized
GitHub — you don’t know where anything’s stored, and even if you did, those
machines aren’t running Git servers that you’re allowed to talk to. I think we
can fix that."_

Hang on, a moment ago you _didn't_ want to run servers. Now you're complaining
that git clones aren't servers?

\-----

Then there's the matter of the github competitors, of which there are many.
gitlab, gitbucket, etc. Some open source, some closed but free, but all of
them largely offer the same features as github.

These days it seems trendy to use bittorrent as a bootstrap for all kinds of
wacky and wonderful problems, but using bittorrent for a protocol that's
already distributed and already pretty saturated with github competitors; well
it just seems redundant.

~~~
ajkjk
I think your complaints are disingenuous. [edit: what I mean is that you've
pointed out problems with small components of the overall article and used
them as an argument against the article as a whole, which I think is unfair. I
don't think the components' validity affects the overall idea.]

His argument may have some holes, and people are probably mostly ignorant of
those holes so they can't critique them, but I don't think they're in awe of
the idea because their awe hasn't been dispelled by identifying those holes.

This is a very neat idea, and none of the issues with the setup argument
dispel that.

"using bittorrent for a protocol that's already distributed and already pretty
saturated with github competitors; well it just seems redundant."

no, no, it doesn't seem redundant. DHT based distributed indexing is so
incredibly fundamentally different than a mirror list for files in FTP or from
a series of GitHub clones. It's owner-agnostic. It just exists, by virtue of
having participants, with no overhead. I don't have to select a target host or
find a server or even identify where my particular file (or git repository, or
username, or whatever) lives. It's .. unification. It's elegant and reduces
complexity and makes the whole ecosystem more simple.

Maybe I'm blinded by my own awe, but, I love this idea.

Also, yes, some people have thought of components of this before, but I
haven't really seen the full stack laid out vertically like this, combined
with a narrative that makes me so excited about it.

~~~
laumars
Thank you for taking the time to respond to my comments :)

There's a few more concerns I have:

1) The whole point of git is versioning, having a model like this breaks makes
versioning several orders of magnitude harder.

2) If I'm pulling from repositories to install on servers, I'd rather grab
them from known trusted sources rather than "the anonymous ether"

I'm normally really receptive to new distribution models, so I don't mean to
be negative for negatives sake. But I'm struggling to see the practical
upsides of this.

~~~
icebraining
The "anonymous ether" isn't dangerous if you have some way of verifying what
they're sending you, and with bittorrent, you do, since you request the
content using its hash.

~~~
laumars
bittorrent hashes as susceptible to collision attacks.

~~~
icebraining
Collision attacks are not really a problem, since they only happen when the
attacker gets to specify the hash, which wouldn't be the case here.

Generating a file that hashes to an existing hash is called a Preimage attack,
and SHA-1 (the algorithm used by bittorrent) isn't, for now and as far as we
know, vulnerable to any.

~~~
laumars
SHA1 is vulnerable to it, but you're right that ive drastically overestimated
the practicality of a preimage attack. Thanks for the correction :)

~~~
cjbprime
Why do you say that SHA1 is vulnerable to second preimage attacks? Zero have
been found.

~~~
laumars
Because anything that's vulnerable to collision attacks is _theoretically_
vulnerable to preimage attacks. Where I went wrong was assuming that preimage
attacks were practical, but as you've rightly said, there's been no known
exploits because of their extreme difficulty.

So it's one of those situations where everyone was right: it's so impractical
to exploit that it's as good as not vulnerable even though it's mathematically
possible.

------
mixmastamyk
Interesting, I'm also very interested in the other project mentioned "bugs
everywhere." Anyone have more details on day to day usage of it?

------
erikb
Git itself is already distributed. Do we really need more distribution or do
we simply need to learn to work more distributed?

~~~
ajkjk
It's clear, though, that there are aspects of 'distributed' that Git does not
accomplish. This gives you a global namespace and a global identity, just like
a website, without a single point of failure or a corporate interest, and with
a closed source system and a trivial option for forking the whole structure
into your own [friend group|company|private cluster|etc].

An argument could be made that git ought to be augmented with something like
this: why run distributed protocol A on distributed protocol B; maybe we
should just run distributed protocol AB from the get-go?

------
placebo
Great. Centralism and monopoly in any form makes me uneasy. This is another
point for freedom...

------
pjc50
I'm very impressed by this, and I'm a bitcoin skeptic and git usability
critic.

------
joe563323
Just awesome idea. The idea of having a torrent for git repos blew my mind.

------
DannoHung
Sweet as hell. My only quibble is the idea of using the blockchain for
validated naming. I think it'd end up in a landgrab which is nasty.

As much as we all hate DNS, having the ability to kick a squatter off
someone's name is _probably_ a good thing. Personally I don't think having a
crazy hash for identification is a bad thing. Rather, what you need to do is
just have some sort of reasonable personal contact book so you only have to
deal with the crazy hash once (when you decide you want to remember that
someone is who they said they were).

~~~
krupan
These are just usernames, not trade marked domain names. What did you do when
someone got to gmail/twitter/whatever before you did and picked the name you
liked? You just picked a different name, or added some digits to the end of
the one you liked. You could do the same thing here.

~~~
DannoHung
My experience has shown that having names be treated as unique identifiers is
a hairy situation. And frankly, unique identifiers in a system for
distributing source code are as important as domain names if not way more so.

Domain names only ever run code in an ostensibly sandboxed vm.

~~~
anewhnaccount
Unlike domain names they're immutable. So if it's good now, it's good as long
as the private key is kept safe.

If you want to cross reference the identity with an email address you could
use a keyserver. If you want to cross reference the identity with a domain
name, you could use a TXT record.

------
Kenji
Haha, that reminds me of my comment earlier:
[https://news.ycombinator.com/item?id=9578307](https://news.ycombinator.com/item?id=9578307)

And plenty of people schooling me that git is already distributed (git yes,
github no). I am happy that someone is working on this.

------
x5n1
There is also Gogs:
[https://github.com/gogits/gogs](https://github.com/gogits/gogs)

------
simplemath
Well, thats a winning name, to be certain. Pretty great work too.

------
ajjai
nice

------
tyuwan
sdfs

