[0] http://ipfs.io
GitTorrent: A Decentralized GitHub
71–80 of 174 posts
Re: GitTorrent: A Decentralized GitHub
#72Earlier 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?
Re: GitTorrent: A Decentralized GitHub
#73Earlier 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.
Re: GitTorrent: A Decentralized GitHub
#74Can 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
Re: GitTorrent: A Decentralized GitHub
#75I think this is a great piece to build a "pay for branch merging" way of promoting open source.. use decentralized currency and voila, automated programming.
Re: GitTorrent: A Decentralized GitHub
#76A 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.
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
#77Earlier 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.
Re: GitTorrent: A Decentralized GitHub
#78Major 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. :)
Re: GitTorrent: A Decentralized GitHub
#79Earlier 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…
Re: GitTorrent: A Decentralized GitHub
#80Earlier 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.