GitTorrent: A Decentralized GitHub • Hacker News Board

Re: GitTorrent: A Decentralized GitHub

#171

Post by anonbanker » Sun, May 31, 2015, 11:19 PM UTC

exDM69 wrote: post #79

rcthompson wrote: post #64

Earlier quoted context omitted.

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?

I regularly download mame updates by pointing the updated torrent at my ROMs directory. All changes are redownloaded, and new ROMs are grabbed.

Edit: just realized I misread the question. No. In my case, the previous mame romset swarm is usually abandoned, and the new torrent takes all the traffic. The swarms are unique.

Re: GitTorrent: A Decentralized GitHub

#172

Post by kragen » Mon, Jun 01, 2015, 1:13 AM UTC

JoshTriplett wrote: post #25

sytse wrote: post #22

Earlier quoted context omitted.

Interesting idea. I think it is harder to do this than the federated merge requests because of the permissions, but I love the idea.

You'd be logged into your "home" instance, which gives you the permissions you need. You click a link on the remote site, which takes you (either directly via URL handler or indirectly via central site redirect) to your home instance with appropriate values filled in, and prompts you to confirm (to avoid CSRF).

That sounds like federated two-click cloning, not federated one-click cloning. Maybe you could batch up the confirmations and get federated 1.1-click cloning?

Re: GitTorrent: A Decentralized GitHub

#173

Post by sytse » Mon, Jun 01, 2015, 2:53 PM UTC

hobarrera wrote: post #166

I like the idea of decentralized, but I'm not sure we need p2p as well. It'd be interesting to see something like gitlab to have some sort of federation support; where multiple instances can talk to one another ( a la xmpp/smtp ), so as to clone/send pull-requests, etc across different instances.

We would love to see features like that in GitLab http://feedback.gitlab.com/forums/176466-general/suggestions...

Re: GitTorrent: A Decentralized GitHub

#174

Post by uptown » Mon, Jun 01, 2015, 3:29 PM UTC

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…

I found this discussion interesting regarding conceptual approaches about how to handle partial torrent updates:

"Thinking about 'meta' torrent file format." https://gist.github.com/mait/8001883

Truly Meta - Meta: https://news.ycombinator.com/item?id=6920244