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

131–140 of 174 posts

Re: GitTorrent: A Decentralized GitHub

#131

Post by rakoo »

fao_ wrote: post #55
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. :)

Perhaps approaching it the way (I assume) TPB does it, and have the comments section, etc, handled through BitTorrent?

TPB is just a website and doesn't use bittorrent at all.

Re: GitTorrent: A Decentralized GitHub

#132

Post by laumars »

ajkjk wrote: post #113
laumars wrote: post #109

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…

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

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.

Re: GitTorrent: A Decentralized GitHub

#133

Post by tperson »

k2enemy wrote: post #71

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

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

[0] http://gateway.ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsN...

Re: GitTorrent: A Decentralized GitHub

#134

Post by icebraining »

yazaddaruvala wrote: post #128
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. :)

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

Decentralized search can be done; Tribler has implemented it for the torrent network, in fact: https://www.tribler.org/ContentSearch/

Re: GitTorrent: A Decentralized GitHub

#135

Post by icebraining »

laumars wrote: post #132
ajkjk wrote: post #113

Earlier quoted context omitted.

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

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

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.

Re: GitTorrent: A Decentralized GitHub

#136

Post by astrobe_ »

Rhapso wrote: post #70
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…

Check out IPFS ( http://ipfs.io/ ) You can use it for git repos essentially out of the box by uploading your repo. It is made of content addressed chunks which will get re-used on each re-upload.

I believe that these technologies are bound to wither not because of technical problems but because of "political" problems. These technologies are a huge problem with the regard to how intellectual property is managed today and how it is monetized.

Every IP owner will try to slow down the progress of these technologies, mainly by not adopting them. I think these technologies won't be adopted until the IP monetization problem is solved.

To me, this means that if the media are to be easily decentralized and shared, the monetization (how you get money for your work and how you give money when you benefit from it) must become equally easily decentralized and shared (between the publishers, authors, etc.).

Re: GitTorrent: A Decentralized GitHub

#137

Post by laumars »

icebraining wrote: post #135
laumars wrote: post #132

Earlier quoted context omitted.

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

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.

Re: GitTorrent: A Decentralized GitHub

#138

Post by rakoo »

tottenhm wrote: post #107
cjbprime wrote: post #77

Earlier quoted context omitted.

Not quite: the peer generates the pack and tells you its hash, and then you query the network for anyone who has that hash (them, for starters), and perform a swarming download of it. So git clones of popular repositories would usually swarm.

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 resource you're interested in, and instead of getting this resource from a single machine and clog their DSL line, you want to get this resource from as many machines as possible to make better use of the network.

How does gittorrent work ?

- The project owner commits and updates a special key in the DHT that says "for this repo, HEAD is currently at 5fbfea8de70ddc686dafdd24b690893f98eb9475"

- You're interested in said repo, so you query the DHT and you know that HEAD is at 5fbfea8de70ddc686dafdd24b690893f98eb9475

- Now you ask each peer who have 5fbfea8de70ddc686dafdd24b690893f98eb9475 for their content

- Each peer builds the diff packfile and sends it through bittorrent. Technically it's another swarm with another infohash, but you don't care; it's only ephemeral anyway. The real swarm is 5fbfea8de70ddc686dafdd24b690893f98eb9475.

Because of this, higher popularity will mean more peers in the swarm, whatever the actual packfile to be exchanged is. Bittorrent the way you know it is not used as-is, because there is information specific to gittorrent that helps make a better use of it.

Re: GitTorrent: A Decentralized GitHub

#139

Post by amirouche »

rakoo wrote: post #93
minot wrote: post #60

Earlier quoted context omitted.

> The un-updateability of torrents is something that seems to seriously limit it's use. I am not involved with the development of torrents at all but (please bear with me until the end) my initial reaction is that we should think of the lack of ability of torrents to update as a feature and not as a bug. Perhaps if ability of torrents to update is a concern then it warrants a new peer to peer protocol? (Please note t…

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

Re: GitTorrent: A Decentralized GitHub

#140

Post by icebraining »

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.

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.

Post reply on HN