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

61–70 of 174 posts

Re: GitTorrent: A Decentralized GitHub

#61

Post by StephenFalken »

nilved wrote: post #51
cxxv wrote: post #17

Earlier quoted context omitted.

Your analogy doesn't hold up, as (for one) we have society and plants don't. I'm glad that child porn is illegal (which is usually distributed in files), as it makes the world safer for children. Also: some plants are serious jerks.

If pi goes on forever, it contains any and all representations of child porn that could exist. The first person to calculate pi that far will be breaking the law. No, that doesn't make sense, nor does any sort of information being illegal. What does make sense is to legislate the actions that can generate that data, or the misappropriation of that data.

Great point !

Re: GitTorrent: A Decentralized GitHub

#62

Post by dpiers »

minot wrote: post #60
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…

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

Support for mutable/updateable torrents was proposed in BEP-0039 (http://www.bittorrent.org/beps/bep_0039.html) and is the basis of how BitTorrent Sync functions.

Re: GitTorrent: A Decentralized GitHub

#64

Post by rcthompson »

minot wrote: post #60
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…

> 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, clients downloading the new torrent could download the first 50 files from clients seeding the old one.) That's updatability without mutability.

Re: GitTorrent: A Decentralized GitHub

#65

Post by rektide »

dpiers wrote: post #62
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…

Support for mutable/updateable torrents was proposed in BEP-0039 ( http://www.bittorrent.org/beps/bep_0039.html ) and is the basis of how BitTorrent Sync functions.

Great to have. Alas it relies on a central system of record, is just a feed that can be re-fetched. The 'originator' key is probably worth standardizing around for any future approaches, but using PEX or the DHT to notify the most recent magnet uri or what not.

Simply signaling new Magnet URI's would have the disadvantage Gittorrent sought to avoid: resyndicating the entire contents with every single change: a killer for things like the Linux kernel or projects like Debtorrent. Git's merkle-dag avoids this problem, allows multiple concurrent versions to share the bulk of the content-indexing, and best-of-all-worlds solutions would preserve this capability.

Re: GitTorrent: A Decentralized GitHub

#68

Post by ackalker »

pjc50 wrote: post #45
ackalker wrote: post #35

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…

Git is built out of deltas. You're already storing all of them.

The problem is not with deltas between revisions (i.e. the commits themselves) but with the Git packs spanning multiple revisions. At the time of a `git pull`, a user's repository can be at any revision between initial and latest. Who is going to seed (and keep seeding) packs for all of those possible revision intervals?

Re: GitTorrent: A Decentralized GitHub

#69

Post by [deleted] »

pjc50 wrote: post #45
ackalker wrote: post #35

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…

Git is built out of deltas. You're already storing all of them.

[deleted]

Re: GitTorrent: A Decentralized GitHub

#70

Post by Rhapso »

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.

Post reply on HN