> Frankly I would be perfectly fine with the current situation where you have a bunch of effectively centralized code hosting solutions (github, gitlab, bitbucket etc...) if you could trivially move your project from one to an other. For the code it's easy, git is built that way. For issues, PRs and the like it's trickier.

Maybe there's a nice way to Gitea distribute this information among Gitea instances, though it doesn't seem advertised as such - as this would basically make Gitea some neat Federated tool i think.

Ultimately i'd like Git[ea|whatever] to be just a frontend for a database that behaves like Git. In the way same way that Github's Source Viewing is just a frontend for Git. You don't worry about moving your Source data between Github and Gitlab, so why are we worrying about universal data like Bug tickets, Feature tracking, etc.

I'm a massive fan of systems that behave like Git and Scuttlebutt. Which is to say, they're dumb - simple. Git can be pushed and pulled from basically everything. There's no complex suite of nodes around the world that are expected or assumed to operate for any Git functionality. In the same way Scuttlebutt - which offers P2P layers, is similarly dumb (though less so, unfortunately) when compared to more complex P2P offerings like IPFS.

In my ideal world we'd have a database to pair with Git that would have some very basic schemas to complement Git. Possibly even baked into Git. Such that when you move from Github to Gitlab to Gitea - everything truly essential comes with. Some things might change, like your CI if it was bound to Github - but still. Losing some things vs losing everything.

I personally am less concerned about using Github/etc. Ie i'm not dying for someone to give me a new Github. I'm seeking a way to reduce lockin.

NOTE: I'm working on a distributed database that fits my needs on my above design goals. Really it's just Git + some additional data structures which allow for more data types being stored, such as binary and structured data to build foundations for SQL layers and etc. It's not intended for general use, but i'd love to see someone pick up the idea and run with it. "Git for Data" has been done a couple times, NomsDB and DoltDB namely, but they still felt like they weren't Git-like in that they wanted to centralize - probably for SaaS reasons.