[michaelmure]

I haven't but I'm not sure it's really necessary. What needs to happen first is a large enough usage of git-bug, or at least a large enough use case coverage. To do so, I think it needs:

- support for pull-requests

- support for external auth in the webUI, to make it work as a public frontend where anyone can browse and interact with bugs like any other forge

If that happens and people are convinced, I'd think that git-bug would become a natural companion for git. Then it's just a matter of packaging.

[hosh]

I had been doodling ideas about a distributed forge. It would allow for a local-first environment. Updates can be broadcast on something lile ActivityPub, and some automatic way to pull from Githuv. Discussions can go there, though git-bug may be the better way to go.

My main goal is resiliency. A typical Elixir/Phoenix project, for example, will have some dependencies on github. If github or the internet goes down, or even disappears, there would be no way for us to rebuild that from source.

[michaelmure]

What you are describing is exactly within git-bug's scope, and really not that far away! I'd love to make that happen, but unfortunately I have a demanding day job and rely on contributor's help.

[hosh]

I have many time commitments as well. I would love yt set aside some time on this.

I’d implement this in Elixir though. I enjoy it, and Elixir has some good stuff for dealing with errors in a distributed system. Put some effort into release engineering.

This is part of my broader interest in a resilient internet. On the foundation of a decentralized forge is a way to do community-supported software. With a forge, the next step would be a way for communities to raise capital (bug bounties, features, kickstarter style), but without having to rely on big platforms to do so.