Files: 73b4b7d083757d91a5151c23eacbe9c6ae615ebf / volume-0 / git-ssb / index.md
distributed collaboration with git-ssb
git is a distributed version control system. Unlike earlier centralized tools for version control, git allows you to make commits offline and to work in parallel on your own fork. With centralized tools like svn and cvs, when you make a commit to a project, your computer sends a network request to a server and your changes must be up to date with the latest version the server knows about.
The distributed version control model pioneered by darcs, bitkeeper, mercurial, and git did away with the bottleneck of a central server to mediate access and synchronize development. In the distributed model of version control, every peer has a complete copy of the entire history for a project. When you make a commit using git, you modify only the files stored on your local machine.
You might be using decentralized version control, but how can you share your
code with other people? Some people email patches to each other with
git am, but the most common way to share your code is
to use an ssh or http server.
Configuring permissions for http and ssh servers can be difficult and git doesn't directly address the question of how to get someone's attention in order to merge their changes into a project. People might use email, irc, or an issue tracker, but the approach varied on a per-project basis.
The git hosting service github came up with a streamlined collaboration workflow called a pull request which provided an integrated solution for how to fork a repository and contribute back your changes. This model has proved extremely popular with free and open source software communities and with proprietary commercial software projects alike.
the problem with github
Entrusting github, a privately held company, to mediate our access to the vast commons of free and open source software is a problem. Presently as of 2016, github provides free hosting and collaboration to public projects in order to promote their business selling hosting and collaboration for private, proprietary projects. This arrangement may not hold forever. What happens if github's margins decline and they need to find new revenue streams? What if they start to see public hosting as a costly burden that no longer can be financially justified as promotion for their hosting service? If github were to suddenly vanish like geocities, what would happen to the communities that have grown up around and depend on their tools?
Another problem is that github is beholden to their bottom line as a business, so the needs of paying customers will always be higher priority than the needs of the community who may not be paying for private hosting at all. github gets to decide what features are important, not the users. Better tools for moderating hostility in issues and preventing abuse might not be as high of a priority for github if it doesn't provide more revenue.
Moving to collaboration and hosting provided by a non-profit using a free and open source hosted server might help to address issues related to feature development, but we would still be left in a situation where access to hosting and collaboration is entrusted to a single point of failure. A single point could be improved by federating redundant backups, but this is only marginally better and the economics of the web have shown over time that federated systems tend toward centralization at scale.
To build a better github, we must first build a better way of exchanging information across the internet than by mediating all communications through servers. We must redecentralize the web in a way that won't suffer the same fate as the early federated web which consolidated into some very large and powerful centralized services. There are many groups working on redesigning fundamental assumptions, but the effort relevant to this article is called secure scuttlebot, or sbot.
Dominic Tarr and contributors have built a distributed messaging platform, sbot, that provides a distributed networking fabric for building strongly decentralized applications. In the sbot network, every user has a feed. Feeds are append-only logs of data as you get with centralized social networks like twitter and facebook. Users also follow each other as with the centralized social networks, but when you follow someone on the sbot network, you also help to host their data. If you want to get the latest updates from a user that is presently offline, you can ask that user's followers for updates, some of whom may be online.
To add redundancy and to help with onboarding, some users run "pub servers". These servers are ordinary clients at the protocol level but happen to have high uptime compared to other clients which may run on laptops and phones. Pubs can be instructed to follow users by their operators, who can share invite codes to onboard new users. Without pubs, it would be very difficult to onboard new users because there would be nobody to follow and nobody would know how to follow you.
Another good way to bootstrap your way onto the sbot network is to share the same wifi network with an existing sbot user. The sbot clients use mdns to broadcast their presence to everyone on the local wifi, so you can follow sbot users by sharing the same wifi.
Local network discovery over wifi also makes sbot work very well for situations where you might have a local network that isn't necessarily online or has a very slow or unreliable uplink to the public internet. sbot is distributed like git, so you can make and read posts completely offline working from whenever you last pulled in data from the users you follow.
At the time of this publication, there are several applications for the sbot network:
- patchwork - a social network feed similar in appearance to facebook or twitter
- patchbay - a more nimble but less polished social network feed
- ferment - music hosting similar to soundcloud
- git-ssb - git project hosting and collaboration
Development has mostly moved from patchwork to patchbay, so in the future it's likely to be a solid replacement. Other clients may emerge, but they should all interoperate on the network so users are free to choose the social networking clients they like best.
git-ssb leverages secure scuttlebot to provide git hosting, issues, and pull
requests. git-ssb uses the built-in extensibilty of git to provide a
command and support for remotes that use the
To get started with git ssb, you first need to get connected to the sbot network. The best way to do this is to install patchwork or patchbay:
$ npm install -g patchwork $ patchwork
Or you can use patchbay, but you'll have to run sbot separately:
# ... # ... # ...
and then hop on irc.freenode.net/#scuttlebot to request an invite from someone who operates a pub. Another option is if you know anyone already on the sbot network, you can meet up in person on the same wifi to join the network. Once you're successfully on the network you can run your own pub server if you want.
Once you're on the sbot network
Built with git-ssb-web