@feld isn't maven basically federated?
@feld yeh I'm not very familiar. I'd have to understand software signing practices and stuff better. but I thought the whole concepts of repos in apt and maven and stuff were to decentralize the load. that and it's already possible to host your own NPM registry, GitHub offers it as a service. GH is centralized but in theory that means you could treat registries as repos, on whatever server, and add the ones you need to a project? idk
@feld yeah I guess to your point git itself is already decentralized, the supplementary development process is really where the problem lies perhaps then a federated GitHub, not git. Which since GH is also an alt NPM it'd be an all inclusive software distribution platform. Maybe that's just a self-hosted like GitLab, but maybe federation enables cross org collaboration??
@feld I'd try and keep git out of it the federation cause like we've said it's already decentralized and the problem is controlling the development process which. Federated JIRA makes sense I think but I guess my original goal is for NPM and GH not to own distribution. Maybe federation doesn't need to be involved in that part either, simply each org self-hosting their distributables. The governance of common libs to be hashed out in that domain i.e. what server vs what username is providing this resource
@feld is the main OS vendor not just a server you trust? You're always gonna have to vet your dependencies. Couldn't formalizing the process a bit (via activity pub extensions?) and enable "third parties" to come online and establish trust more easily? If a project could fork Ubuntu's process by propping up an instance, then their modifications can be audited as a more clean diff of procedure? I'm thinking maybe it's a leveling of the playing field kinda? Auditing is inescapable though
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!