diff options
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 36 |
1 files changed, 18 insertions, 18 deletions
@@ -1,26 +1,26 @@ -#  +#  ### The Decentralization of GitHub -**GitSwarm** is a peer-to-peer network of Git repositories being shared over BitTorrent. +**GitTorrent** is a peer-to-peer network of Git repositories being shared over BitTorrent. To get started: ``` -npm install gitswarm +npm install gittorrent ``` After that, you can clone a repo with: ``` -git clone gitswarm://github.com/someuser/somerepo +git clone gittorrent://github.com/someuser/somerepo ``` Or serve your own repos with: ``` touch somerepo/.git/git-daemon-export-ok -gitswarmd +gittorrentd ``` # Design -The design of GitSwarm has five components: +The design of GitTorrent has five components: 1. A "git transport helper" that knows how to download and unpack git objects, and can be used by Git itself to perform a fetch/clone/push. 1. A distributed hash table that advertises which git commits a node is willing to serve. 1. A BitTorrent protocol extension that negotiates sending a packfile with needed objects to a peer @@ -31,28 +31,28 @@ The design of GitSwarm has five components: When Git is asked to perform a network operation with a URL that starts with e.g. `someprotocol://`, it calls `git-remote-someprotocol` and passes the URL as an argument. The remote helper binary is responsible for telling Git what capabilities it has, receiving commands from Git, and downloading objects into the `.git/` directory. -In GitSwarm's case, we could be asked for three styles of URL: +In GitTorrent's case, we could be asked for three styles of URL: * `gittorrent://some.git.hosting.site/somerepo` -- we connect over `git://` to find out what the latest commit is, then perform the download using that commit's sha1. This is kind of like a [CDN](CDN) for a git server; the actual download of objects happens via peers, but the lookup of which objects to downloads happens in the normal Git way. -* `gitswarm://<hex sha1>/reponame` -- the sha1 corresponds to a gitswarm user's "mutable key" (hash of their public key) on our DHT -- we look up the key, receive JSON describing the user's repositories, and then perform the download using that commit's sha1. This doesn't use any resources outside of GitSwarm's network. -* `gitswarm://<username>` -- the username is converted into a mutable key sha1 as above. The mapping from usernames to happens on Bitcoin's blockchain in OP_RETURN transaction. +* `gittorrent://<hex sha1>/reponame` -- the sha1 corresponds to a gittorrent user's "mutable key" (hash of their public key) on our DHT -- we look up the key, receive JSON describing the user's repositories, and then perform the download using that commit's sha1. This doesn't use any resources outside of GitTorrent's network. +* `gittorrent://<username>` -- the username is converted into a mutable key sha1 as above. The mapping from usernames to happens on Bitcoin's blockchain in OP_RETURN transaction. ## 2. Distributed hash table -The bootstrap server for this DHT runs at `core.gitswarm.org:6881`. It is a bittorrent mainline DHT. Git SHA1s are announced by nodes who can create packfiles for them. The clients on this DHT support dht-store (BEP 44) and use it to store mutable keys. +The bootstrap server for this DHT runs at `core.gittorrent.org:6881`. It is a bittorrent mainline DHT. Git SHA1s are announced by nodes who can create packfiles for them. The clients on this DHT support dht-store (BEP 44) and use it to store mutable keys. ## 3. Protocol extension Once a client has connected to another node, it sends a request for the SHA1 it's looking for as bencoded JSON: ``` -{gitswarm: ask: "sha1"} +{gittorrent: ask: "sha1"} ``` The node providing the packfile returns: ``` -{gitswarm: sendTorrent: "infoHash"} +{gittorrent: sendTorrent: "infoHash"} ``` ## 4. Key/value store -BEP 44 adds support for *mutable* and *immutable* keys. Immutable keys are addressed by the hash of their content, but mutable keys are addressed by the hash of a crypto keypair's public key. The owner of that keypair publishes signed updates to their public key's hash, with a sequence number to ensure the latest value is always propagated by peers. The hash of the public key here is a GitSwarm user ID, and the value associated with that key is a JSON object describing the user's repositories in a User Profile. +BEP 44 adds support for *mutable* and *immutable* keys. Immutable keys are addressed by the hash of their content, but mutable keys are addressed by the hash of a crypto keypair's public key. The owner of that keypair publishes signed updates to their public key's hash, with a sequence number to ensure the latest value is always propagated by peers. The hash of the public key here is a GitTorrent user ID, and the value associated with that key is a JSON object describing the user's repositories in a User Profile. ### User Profile JSON format * name (string) @@ -79,22 +79,22 @@ The idea of using OP_RETURN comes from telehash's blockname project, but while b ``` e.g. ``` -@gitswarm!cjb!81e24205d4bac8496d3e13282c90ead5045f09ea +@gittorrent!cjb!81e24205d4bac8496d3e13282c90ead5045f09ea ``` -Note that OP_RETURN transactions are limited to 80 bytes, which limits usernames in this scheme to 29 bytes. +Note that OP_RETURN transactions are limited to 80 bytes, which limits usernames in this scheme to 27 bytes. -As a convenience, this repository will include a database of registered usernames that is updated regularly. This doesn't make GitSwarm any more centralized -- you can run the same scripts yourself on a downloaded blockchain to make sure that this repository does not lie. This is just to save everyone from downloading tens of gigabytes of blockchain to process. +As a convenience, this repository will include a database of registered usernames that is updated regularly. This doesn't make GitTorrent any more centralized -- you can run the same scripts yourself on a downloaded blockchain to make sure that this repository does not lie. This is just to save everyone from downloading tens of gigabytes of blockchain to process. By the way, storing full Bitcoin history is not necessary. We just need to scan every transaction once, and can discard each transaction after we've scanned it once and determined whether it contained a valid username registration that we record. We just need to scan through all unprocessed blockchain transactions once, and record where we got up to so that we don't have to look at them again after that. ## Contributing -Please send pull requests! Even changes to the design of GitSwarm are welcome and encouraged; nothing is set in stone. +Please send pull requests! Even changes to the design of GitTorrent are welcome and encouraged; nothing is set in stone. #### JavaScript Standard Style -GitSwarm uses [JavaScript Standard Style](https://github.com/feross/standard). +GitTorrent uses [JavaScript Standard Style](https://github.com/feross/standard). [](https://github.com/feross/standard) |