3 ms·

So, I think there's a couple relevant issues when talking about decentralizing a github like service. There a couple of things Github provides, and my naive app

So, I think there's a couple relevant issues when talking about decentralizing a github like service. There a couple of things Github provides, and my naive approach to making GitHub less essential would be to address them one by one: * Issue tracking. It's a bit hard to export these. I imagine it'd be a bit nicer to export if issues were actually stored inside git as trees. You could easily make the issues frontend use git as the storage backend. If users don't have an account, maybe they could issue a pull-request to the issue tracker? * Notifications. This ones's a bit harder. Web-hooks? * Merge requests - github uses refs internally (I think). That wouldn't be too hard to standardize. If somebody adds commits to their pull/merge request, then they just have to push the updated ref to the repo they're submitting to. * Auth - this is hardest part. GitHub provides authentication & permissions for pushing. The issue with allowing merge requests submission from anybody (which you could do with a server side hook) is that now people can ddos you by submitting HUGE pull requests constantly. If you could make that safe, in theory you could get away without needing user account federation. * There is also the big security issue that you can't actually use server side hooks for this stuff since libgit2 can be used to bypass it (when pushing using libgit2, it doesn't trigger server side hooks). * Oh, and this entire time I've been thinking about the email & username as being unspoofable. But you can easily spoof them. I guess you need federated user accounts after all. Edit: It's untrusted interactions that's hard to decentralize --------------- All in all, I think that git is easily decentralized if you know you can trust all the actors. It's untrusted git that's harder to decentralize.

djsumdog 8y ago
I mean, the author is decentralizing the basic download and cloning of git. The protocol lets us do that. Git by itself doesn't have issue tracking, wikis, etc. Those are part of Github/lab/bucket. Should the git project seek to add this as part of the repo and protocol itself? Or should we be making new protocols and repositories for this meta-project/code data? I haven't tried Fossil yet, but I understand it has a lot of this stuff built into its protocol/repository format.
balefrost 8y ago
When I wanted to read the SQLite source code, I was surprised to learn that the authoritative copy isn't stored in a Git repo, but rather in something called Fossil SCM (https://fossil-scm.org/ https://fossil-scm.org/). It turns out that it's a SCM built on SQLite and created specifically to store the SQLite source code. Interestingly, it has built-in issue tracking and a wiki. I wouldn't necessarily expect people to switch from Git to Fossil. I certainly haven't. But I found it fascinating and figured others might as well.
chriswarbo 8y ago
Regarding issues, the article mentions storing them in the repo using BugsEverywhere. I use Artemis for this since it's simpler than BugsEverywhere. I don't think "pull requests" are necessary for such a system. Even if you like the pull request workflow (I personally find it tedious and cumbersome) it can be achieved via existing mechanisms like personal email, mailing lists, IRC, pastebin, etc. Trying to define one workflow and baking it into a protocol sounds like a receipe for bloat. Note that git already has built-in support for email. Regarding authentication and permissions: I don't think git is any different from other mutable collection of files in this regard. For example, I push my git repos to IPFS just like any other files, and use IPNS to point at the latest version. IPNS uses keypairs to limit access, which is a pretty standard technology with known practices for things like revocation, indirection, etc. Notifications are just another 'mutable collection of files', e.g. an RSS feed, so solvable in the same way.

djsumdog 8y ago

I mean, the author is decentralizing the basic download and cloning of git. The protocol lets us do that. Git by itself doesn't have issue tracking, wikis, etc. Those are part of Github/lab/bucket. Should the git project seek to add this as part of the repo and protocol itself? Or should we be making new protocols and repositories for this meta-project/code data? I haven't tried Fossil yet, but I understand it has a lot of this stuff built into its protocol/repository format.

balefrost 8y ago

When I wanted to read the SQLite source code, I was surprised to learn that the authoritative copy isn't stored in a Git repo, but rather in something called Fossil SCM (https://fossil-scm.org/ https://fossil-scm.org/). It turns out that it's a SCM built on SQLite and created specifically to store the SQLite source code. Interestingly, it has built-in issue tracking and a wiki. I wouldn't necessarily expect people to switch from Git to Fossil. I certainly haven't. But I found it fascinating and figured others might as well.

chriswarbo 8y ago

Regarding issues, the article mentions storing them in the repo using BugsEverywhere. I use Artemis for this since it's simpler than BugsEverywhere. I don't think "pull requests" are necessary for such a system. Even if you like the pull request workflow (I personally find it tedious and cumbersome) it can be achieved via existing mechanisms like personal email, mailing lists, IRC, pastebin, etc. Trying to define one workflow and baking it into a protocol sounds like a receipe for bloat. Note that git already has built-in support for email. Regarding authentication and permissions: I don't think git is any different from other mutable collection of files in this regard. For example, I push my git repos to IPFS just like any other files, and use IPNS to point at the latest version. IPNS uses keypairs to limit access, which is a pretty standard technology with known practices for things like revocation, indirection, etc. Notifications are just another 'mutable collection of files', e.g. an RSS feed, so solvable in the same way.