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 th

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.