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

141–150 of 174 posts

Re: GitTorrent: A Decentralized GitHub

#141

Post by amirouche »

scotchmi_st wrote: post #33
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.

It's the same old problem of trying to build a peer-to-peer social network. How do you ensure that large files are distributed correctly and quickly with minimal security implications in an environment where nodes are constantly joining and leaving the network? Perhaps it's possible, but if it were an easy way of doing it, there would be more of that sort of thing around.

> How do you ensure that large files are distributed correctly and quickly with minimal security implications in an environment where nodes are constantly joining and leaving the network?

The owner of a project will keep a node always online to fight its own churn. There is no big files in the case of issue tracker. This is not video social network. Also, video social network do work, e.g. private trackers, the only thing is that they use the web publish magnet links which can be done over a DHT cf. PPSP and tribler.

Re: GitTorrent: A Decentralized GitHub

#142

Post by stevekemp »

ShaneWilton wrote: post #124
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…

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

Unfortunately Tahoe-LAFS is something I've been looking at recently and it suffers from a few missing features which have been known for many years.

(The one that I want most is the ability to rebalance on the fly, as storage-hosts become full.)

Re: GitTorrent: A Decentralized GitHub

#143

Post by anewhnaccount »

DannoHung wrote: post #103
krupan wrote: post #52

Earlier quoted context omitted.

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.

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.

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.

Re: GitTorrent: A Decentralized GitHub

#144

Post by cjbprime »

rakoo wrote: post #138
tottenhm wrote: post #107

Earlier quoted context omitted.

The probability of swarming would be influenced by multiple factors, eg * Higher popularity => More peers => Higher probability that multiple peers want the same packfiles. * Higher popularity => More commits => More permutations of packfiles => Lower probability that multiple peers want the same packfiles (and stronger trends toward small/inefficient packfiles). * More frequent synchronizations (peers always online)…

> Could this be mitigated with some constraints on how peers delineate packfiles? YAGNI. Like so many here, you have a single view of how bittorrent should be used, based on current filesharing practices, so you believe we need to map gittorrent to filesharing and have those packfiles be as static as possible in order to be shared at large. You need to go back to the root of the problem, which is simple: there is a r…

(Author here.)

Great comment, thank you. But I think the infohash should actually be shared, packfiles are pretty deterministic in practice. So you'd be getting the diff packfile from the person who just made it, and anyone else who already did.

(If I find packfile generation to not be deterministic enough, I think I'll switch to using a custom packfile generation that is always deterministic.)

Re: GitTorrent: A Decentralized GitHub

#145

Post by cjbprime »

laumars wrote: post #137
icebraining wrote: post #135

Earlier quoted context omitted.

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.

bittorrent hashes as susceptible to collision attacks.

Git and bittorrent use exactly the same hash format (sha1); bittorrent is no more susceptible than Git.

Re: GitTorrent: A Decentralized GitHub

#146

Post by JoshTriplett »

stevekemp wrote: post #142
ShaneWilton wrote: post #124

Earlier quoted context omitted.

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

Unfortunately Tahoe-LAFS is something I've been looking at recently and it suffers from a few missing features which have been known for many years. (The one that I want most is the ability to rebalance on the fly, as storage-hosts become full.)

Tahoe-LAFS also doesn't support deletion.

Re: GitTorrent: A Decentralized GitHub

#147

Post by askmike »

brasky wrote: post #119
TimJRobinson wrote: post #115

Earlier quoted context omitted.

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.

Like http://storj.io/ ? I think they have a lot of code to write though.

Don't forget http://maidsafe.net/

Re: GitTorrent: A Decentralized GitHub

#148

Post by ianopolous »

m_mueller wrote: post #121
TimJRobinson wrote: post #115

Earlier quoted context omitted.

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.

We're trying to recreate that concept with peergos, https://github.com/ianopolous/Peergos we're considering trying to use ipfs, 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.

Re: GitTorrent: A Decentralized GitHub

#150

Post by rakoo »

amirouche wrote: post #139
rakoo wrote: post #93

Earlier quoted context omitted.

> Perhaps if ability of torrents to update is a concern then it warrants a new peer to peer protocol? There is a new peer to peer protocol, it's even an IETF draft, it's called PPSP and is full of nice stuff: https://tools.ietf.org/html/draft-ietf-ppsp-peer-protocol-12 https://github.com/libswift/libswift

Do you imply that PPSP's live stream protocol could be used to create updateable keys?

Yes, if append-only is enough then a streaming protocol like PPSP is good.

Otherwise we need something else, which I hope to achieve in rakoshare (https://github.com/rakoo/rakoshare).

Post reply on HN