Right but because they're otherwise decentralised it would take co-ordinated effort and ultimately it fragments the community. What we need, if we want to solve this issue, is a federated network of servers which provide the functionality of github today.
I want stuff like the issue tracker/merge request dialog to be consistent across the federation (and of course for projects elsewhere in the network to be able to be the source for those merge requests)
I don't want an account on everybody's git{lab,hub,ea,xxx} instance I want a single identity that people can trust is me.
I want a way to discover and index other projects on the network. The same way that I often just go to github without knowing the name of a project just roughly what I'm looking for.
> I don't want an account on everybody's git{lab,hub,ea,xxx} instance I want a single identity that people can trust is me.
I know blockchain is excessively overhyped, but to my limited understanding this appears to be a good fit...
Look at how cryptocurrencies work, a wallet is singular (i.e your identity), exchanges and mining pools are numerous and independent (hosts and services for git repos).
The vital part to make this work is a specification for storing the social aspects of collaborating on these platforms in a git repo itself - it can definitely be done, git is so flexible, it doesn't have to interfere with the project code or even need to be present in the visible tree of any branch - but we need that for interchangeability. This first step could be made before figuring out how to make neatly interacting network to add portability to existing platforms.
Yes, I think identity management/authentication/trust is a problem space that should be separate from version control, because it can serve so many other interesting applications.
By the way, I'm not sure if something like a blockchain is necessary here. You could use a simple public key cryptosystem, where your identity equals the public key, and you prove that you have that identity by using your private key in a challenge/response scheme, and you can also sign messages/commits/whatever by using your private key.
> By the way, I'm not sure if something like a blockchain is necessary here. You could use a simple public key cryptosystem.
I think you're right public crypto is enough... i'm just applying blockchain unnecessarily.
I can see this working in a really nice way: right now people are dealing with "migrating" and having to choose to loose PR/issues starts etc that these platforms provide, all of that could be implicit to the repo with zero effort to use a different platform.
- Public crypto for repo authority (who can commit, who can merge PRs, who can manage issues etc - preferably more granularity than current platforms)
- A common Issues/PRs etc format is saved into the repo
- Hosts are networked, they sync repos with each other allong with any platform data... anyone can add (sync) a repo from github to gitlab without being the author (ownership is done by crypto not platform accounts, each platform/host would verify the repo content when syncing from some other host).
In other words, platforms like github and gitlab etc just become a viewport and a node in the network, like there are GUIs for git, github would be just another GUI for the collaboration protocols... at this point you could even do it offline with a headless server, the purpose of github/gitlab is to provide hosting and good UX etc. This would mean that a repo can simultaneously exist on any platform, there is no platform boundary, you could accept a PR from a user using gitlab on github... it wouldn't matter where they came from. Or if you hate all these platforms you can just use the cli and accept a PR from someone using these platforms (you would just need a public git host that the other host/platforms can sync with).
How the crypto integrates with the repo would have to be well thought out as it's essentially completely independent of platform accounts, anyone could locally clone the repo and attempt to push something to your public server (or a hosting platforms server on your behalf).
Accounts/authorization is already semi-federated through oauth etc. You can sign in to gitlab.com using your github.com account.
We still have only one kind of namespacing and for users and projects: domains, leveraged by Java (and go, others?) for packages, and email for identity.
Discoverability is really a matter of indexes and catalogs; npm, pypi, Google and duckduckgo.
Delegating login is actually useful for self-hosted vcs/issue trackers: not as low friction as just sending an email with a patch; but it's easier to be able to "sign in" with an existing account, add an issue/code - and get notifications via email - rather than having to manage an account for every program you use and find bugs in...
reply