logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

Git-is-already-distributed.md (7351B)


  1. ---
  2. date: 2018-07-23
  3. layout: post
  4. title: Git is already federated & decentralized
  5. tags: [git, philosophy]
  6. ---
  7. There have always been murmurs about "replacing GitHub with something
  8. decentralized!", but in the wake of the Microsoft acquisition these murmurs have
  9. become conversations. In particular, this blog post is a direct response to
  10. forge-net (formerly known as [GitPub][gitpub]). They want to federate and
  11. decentralize git using ActivityPub, the same technology leveraged by Mastodon
  12. and PeerTube. But get this: git is already federated *and* decentralized!
  13. [gitpub]: https://github.com/git-federation/gitpub
  14. I already spoke at length about how a large minority of the git community uses
  15. email for collaboration in my [previous article][last-article] on the subject.
  16. Definitely give it a read if you haven't already. In this article I want to
  17. focus on comparing this model with the possibilities afforded by ActivityPub
  18. and provide direction for new forge[^1] projects to work towards embracing and
  19. improving git's email-based collaboration tools.
  20. [last-article]: https://drewdevault.com/2018/07/02/Email-driven-git.html
  21. [^1]: Forge refers to any software which provides comprehensive tools for project hosting. This originally referred to SourceForge but is now a category of software which includes GitHub, BitBucket, GitLab, Gogs/Gitea, etc.
  22. The main issue with using ActivityPub for decentralized git forges boils down to
  23. email simply being a better choice. The advantages of email are numerous. It's
  24. already standardized and has countless open source implementations, many in the
  25. standard libraries of almost every programming language. It's decentralized and
  26. federated, and it's *already* integrated with git. Has been since day one! I
  27. don't think that we should replace web forges with our email clients, not at
  28. all. Instead, web forges should embrace email to communicate with each other.
  29. Let me give an example of how this could play out. On my platform,
  30. [sr.ht](https://meta.sr.ht), users can view their git repositories on the web
  31. (duh). One of my goals is to add some UI features here which let them select a
  32. range of commits and prepare a patchset for submission via [git
  33. send-email][git-send-email]. They'll enter an email address (or addresses) to
  34. send the patch(es) to, and we'll send it along on their behalf. This email
  35. address might be a mailing list on another sr.ht instance in the wild! If so,
  36. the email gets recognized as a patch and displayed on the web with a pretty diff
  37. and code review tools. Inline comments automatically get formatted as an email
  38. response. This shows up in the user's inbox and sr.ht gets copied on it, showing
  39. it on the web again.
  40. [git-send-email]: https://www.git-scm.com/docs/git-send-email
  41. I think that workflow looks an awful lot like the workflow forge-net hopes to
  42. realize! Here's where it gets good, though. What if the emails the user puts in
  43. are `linux-kernel@vger.kernel.org` and a handful of kernel maintainers? Now your
  44. git forge can suddenly be used to contribute to the Linux kernel! ActivityPub
  45. would build a *second*, incompatible federation of projects, while ignoring the
  46. already productive federation which powers many of our most important open
  47. source projects.
  48. git over email is already supported by a tremendous amount of open source
  49. software. There's tools like [mailman][mailman] which provide mailing lists and
  50. public archives, or [public-inbox][public-inbox], which archives email in git,
  51. or [patchworks][patchworks] for facilitating code review over email. Some email
  52. clients have grown features which make them more suitable for git, such as
  53. [mutt][mutt]. These are the nuts and bolts of hundreds of important projects,
  54. including Linux, *BSD, gcc, Clang, postgresql, MariaDb, emacs, vim, ffmpeg,
  55. Linux distributions like Debian, Fedora, Arch, Alpine, and countless other
  56. projects, including git itself! These projects are incredibly important,
  57. foundational projects upon which our open source empire is built, and the tools
  58. they use already provide an open, federated protocol for us to talk to.
  59. [mailman]: https://www.gnu.org/software/mailman/
  60. [public-inbox]: https://public-inbox.org/
  61. [patchworks]: http://jk.ozlabs.org/projects/patchwork/
  62. [mutt]: http://mutt.org
  63. Not only is email *better*, but it's also *easier* to implement. Programming
  64. tools for email are very mature. I recently started experimenting with building
  65. an ActivityPub service, and it was crazy difficult. I had to write a whole lot
  66. of boilerplate and understand new and still-evolving specifications, not to
  67. mention setting up a public-facing server with a domain and HTTPs to test
  68. federation with other implementations. Email is comparatively easy, it's built
  69. into the standard library. You can shell out to git and feed the patch to the
  70. nearest SMTP library in only a handful of lines of code. I bet every single
  71. person who reads this article already has an email address, so the setup time
  72. approaches zero.
  73. Email also puts the power in the hands of the user right away. On Mastodon there
  74. are occasional problems of instance owners tearing down their instance on short
  75. notice, taking with them all of their user's data. If everything is being
  76. conducted over email instead, all of the data already lives in the user's inbox.
  77. Freely available tools can take their mail spool and publish a new archive if
  78. our services go down. Mail archives can be trivially made redundant across many
  79. services. This stuff is seriously resilient to failure. Email was designed when
  80. networks were measured in bits per second and often connected through a single
  81. unreliable route!
  82. I'm not suggesting that the approach these projects use for collaboration is
  83. perfect. I'm suggesting that we should embrace it and solve these problems
  84. instead of throwing out the baby with the bathwater. Tools like `git send-email`
  85. can be confusing at first, which is why we should build tools like web forges
  86. that smooth over the process for novices, and write better docs to introduce
  87. people to the tools (I recently [wrote a guide][guide] for sr.ht users).
  88. [guide]: https://man.sr.ht/git.sr.ht/send-email.md
  89. Additionally, many popular email clients have bastardized email to the point
  90. where the only way to use git+email for many people starts with abandoning the
  91. email client they're used to using. This can also be solved by having forges
  92. send the emails for them, and process the replies. We can also support open
  93. source mail clients by building better tools to integrate our emails with them.
  94. Setting up the mail servers on the other end can be difficult, too, but we
  95. should invest in better mail server software, something which would definitely
  96. be valuable even setting aside the matter of project forges.
  97. We need to figure out something for bugs as well, perhaps based on Debian's work
  98. on [Debbugs](https://www.debian.org/Bugs/). Other areas of development, such as
  99. continuous integration, I find are less difficult problems. Many build services
  100. already support sending the build results by email, we just need to find a way
  101. to get our patches to them (something I'm working on with sr.ht). But we should
  102. take these problems one step at a time. Let's focus on improving the patch
  103. workflow git endorses, and as our solutions shake out the best solutions to our
  104. other problems will become more and more apparent.