Not only is this a great idea but there's no reason this couldn't be an API layer over any number of underlying source control implementations (Git, Mercurial, Bazaar, TFVC, SVN, etc). Could open up all kinds of possibilities for CI/CD tooling and workflows as well.
The scope of GitPub is still under active definition, and it might end up not being specific to git only.
If you're a stakeholder of any service that could federate based on Mercurial, Bazaar… you're more than welcome to give your input to the working group.
For sure, is there already a proposal for federated merge requests? Or can you make those from the activity stream? That would by the minimal viable change as far as I can see.
First thing first: I would hope that "Git" would be removed from the GitPub name. I'm in favor of replacing Git in the process and having both a new client source control implementation and server API set (SourcePub?) that are designed with each other in mind, eases federation, and is both powerful and easier for new devs than Git (Hg managed this... not sure why a Git replacement can't do the same).
GitPub (or whatever it'll be named then) does not intend to replace git or any other VCS. Its stated goal is to enable federation between services such as GitHub, GitLab, Gogs, Gitea, Pagure… which happen to use git.
In other words, it means that if GitPub was adopted by these services, you could submit a merge request from Pagure to Gitlab, or star a GitHub project from your own Gitea instance, among many other things.
Well in this case why Github, GitLab, etc.. do not allow you to "star" a repo more than once?
I'm fine with stars not being significant, but it's still not good if a malicious actor can suddenly spoof hundreds of accounts and spam stars, comments and what-not.
Because that's a completely different interaction. You can still create another account and star it again.
Sure, your IP will be rate-limited (GH at least) if you script it and start hammering stars, but that's not because it wants to protect the integrity of the repo star count.
I really hope they stick with Git and produce something concrete rather than trying to shoehorn a diverse collection of version control models into the same API. The last thing you want is the sort of lowest common denominator solution that everyone agrees on but is otherwise useless.
Later, after the GitPub federation approach is proven, let another team take up the torch for AnyPub.
To me it seems like the real power of and differences between tools is apparent mostly in the context of offline history editing. Once you're making pull requests, nobody wants anything complex in the PR. Lowest common denominator - "here is a set of commits" might be fine.
