Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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.


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.


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


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


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.


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


They use hashes for different features though. Ie You don't pull chunks anonymously with git




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: