Is git-bug something federative? something like matrix or email?

[ghost]

Hi all. I would like to know what you all think of the idea...

The idea

My idea would be that git-bug could be an issue sharing server. This would allow different people to send and receive issues on different services. That is, each person has the git-bug-server and shares it in different services. That is, something like the email or matrix protocol. Something federative.

The interesting thing about this idea would be to provide a financial means to help the project. People could help the project through a monthly issue storage plan. This guarantees high availability in case any service to which we are connected goes down or ceases to exist or goes off the air for some time. Also, each person could earn money by maintaining plugins to increase issue sharing.

Another complementary idea would be to have a monthly, annual or daily limit for issues created. This would avoid any spamming or over-automating the git-bug for different services. This I consider to be innovative as it is something that some git servers don't have a means or way to identify spam or over-automation. Also, they're not federated servers, which means I can't share git-issues on another server git.

So... I speak of these ideas, because there is no git-bug-server yet, what I perceive would be the client-git-bug. So... it's just a last question and not a feature request.

Is git-bug something federative? something like matrix or email?

[MichaelMure]

So, all of that is very much in the realm of the possible, and in line with how git-bug was designed.

git-bug is already capable of meshing and exchange data in arbitrary topologies, relying on git's remote system. It's more cumbursome than a fully friction-free federation or p2p exchange, but it's not so far off.

Now, if you are familiar with for example IPFS, you might see that it goes further. Deep down, git-bug express each bug into an append-only DAG made of data blocks. Those blocks and the DAG itself exist in a unique content-addressed space. You can have arbitrary many bugs, and in fact git-bug was design to be able to have all the bugs from all projects in that same space.

Point is, there is no arbitrary limitation as you would have in a normal database, software forge ... As long as you are able to exchange data blocks, you can design your social or commercial topology the way you want, and relatively simply at that.

At the moment, git-bug can't be qualified as a server due to a small limitation: there is nothing to react when data is pushed to it, which means nothing to control data integrity and so on. It has been discussed in the issues a few times and really should happen at some point, just didn't yet. At the end of the day, it's a small thing missing.

[ghost]

Hi MichaelMure, thank you for feedback.