Live data from Hacker News

GitTorrent: A Decentralized GitHub

blog.printf.net

71–80 of 174 posts

Re: GitTorrent: A Decentralized GitHub

#72
post #55

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?

Comments, issues, etc could also be objects that are updated through the protocol, and signed with a public key.

Re: GitTorrent: A Decentralized GitHub

#73
post #55

Earlier quoted context omitted.

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

Comments, issues, etc could also be objects that are updated through the protocol, and signed with a public key.

That's roughtly what I was thinking, yeah.

Re: GitTorrent: A Decentralized GitHub

#74
post #14

Can I clone GitTorrent with GitTorrent?

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

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

Re: GitTorrent: A Decentralized GitHub

#76

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

My impression was that peers are generating the deltas on-the-fly based on which commits the requesting peer states it needs. The problem's therefore shoved onto git itself, with the seeder just cherry-picking a specific range of commits from its own copy of the repo and bundling them together.

Ah, okay, but that would imply that GitTorrent doesn't make any use of the swarming capability which makes BitTorrent special.

Not using swarming brings back all of the old problems of NAT traversal, asymmetric upload/download bandwidth, throttling, censorship etc.

Re: GitTorrent: A Decentralized GitHub

#77

Earlier quoted context omitted.

My impression was that peers are generating the deltas on-the-fly based on which commits the requesting peer states it needs. The problem's therefore shoved onto git itself, with the seeder just cherry-picking a specific range of commits from its own copy of the repo and bundling them together.

Ah, okay, but that would imply that GitTorrent doesn't make any use of the swarming capability which makes BitTorrent special. Not using swarming brings back all of the old problems of NAT traversal, asymmetric upload/download bandwidth, throttling, censorship etc.

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.

Re: GitTorrent: A Decentralized GitHub

#78

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

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?

Re: GitTorrent: A Decentralized GitHub

#79
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…

Updatability does not need to imply mutability. It could be possible to have a torrent with 50 files, and then the torrent is updated with a new file, and a client that has already downloaded the new torrent will only need to download one new file. And another client that still wants the old torrent would still get the same 50 files, but would be able to download from clients that have the new torrent. (Similarly, cl…

Follow-up question: does BitTorrent work this way currently? If I take your 50-file torrent, add one file and re-seed, will you be seeding the original 50 files in the same swarm as my 51 file torrent?

Re: GitTorrent: A Decentralized GitHub

#80

Earlier quoted context omitted.

Centralization is about equivalent to ICANN being able to kick off a squatter. A truly decentralized system with first to register doesn't have a way to kick off squatters.

Well, the current ones don't, but it could. Decentralized networks just need decentralized decision, ie., you could have a process by which the majority of the nodes decide to kick off a squatter.

At which point someone uses a botnet to game the system.
Post reply on HN