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

GitTorrent: A Decentralized GitHub

blog.printf.net

Post reply on HN
Print view View original

121–130 of 174 posts

Re: GitTorrent: A Decentralized GitHub

#121

Post by m_mueller »

TimJRobinson wrote: post #115
ChuckMcM wrote: post #95

Earlier quoted context omitted.

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 clou…

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.

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.

Re: GitTorrent: A Decentralized GitHub

#123

Post by jdmichal »

rcthompson wrote: post #110
jdmichal wrote: post #106

Earlier quoted context omitted.

So basically, git over IP? Each "update" is just a commit containing the modifications since the last one. If you want the most recent, ask for the HEAD.

The article goes into why that's not really an option. Making a separate request for each blob/file/commit/whatever would be way too slow for large repos.

I was more commenting that the very updatability you were discussing is pretty much directly analogous to what git is in the first place. So now we're building a system that has the same functions as git, but isn't git.

Re: GitTorrent: A Decentralized GitHub

#124

Post by ShaneWilton »

ChuckMcM wrote: post #95
rektide wrote: post #38

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 i…

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 clou…

If I'm not mistaken, other than the Git specific aspects, this is more or less what Tahoe-LAFS strives to accomplish.

http://en.wikipedia.org/wiki/Tahoe-LAFS

Re: GitTorrent: A Decentralized GitHub

#126

Post by viraptor »

namecast wrote: post #48
DannoHung wrote: post #46

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…

Hmm. How about mixing and matching, like by having a DNS record with a special TXT record syntax, e.g. 'IN TXT "gt=yoursha256hash"'. That way you could find your destination via DNS and verify the hash in the TXT record against the blockchain.

Sounds like what ipfs guys are doing for naming:

> We plan to transition to hosting it on IPFS as soon as DNS -> IPNS -> IPFS naming proves robust, so we can use nice looking URLs.

http://ipfs.io/

Re: GitTorrent: A Decentralized GitHub

#127

Post by viraptor »

cjbprime wrote: post #81
colund wrote: post #74

Earlier quoted context omitted.

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

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

Or without polluting global namespace:

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

Re: GitTorrent: A Decentralized GitHub

#128

Post by yazaddaruvala »

cjbprime wrote: post #37
arxpoetica wrote: post #19

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.

(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. :)

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.

Re: GitTorrent: A Decentralized GitHub

#129

Post by gbog »

exDM69 wrote: post #78
cjbprime wrote: post #37

Earlier quoted context omitted.

(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. :)

What about using git notes (`man git-notes`) for tracking issues, comments, etc? They are stored as git objects (right?) and could be used for this task?

I thought about using git notes for this and didn't how it is better than adding issues, comments and wiki inside the repo itself. We are used to put documentation and tests alongside the code in our repo, why not add wiki and issues?
Post reply on HN