Isn't gpg already a convenient cli for basic gpg tasks? We have had public keystores (much like github) for decades. There are probably already links to some on your system.
Well, it isn't a PITA for me, and I couldn't imagine pointing my grandmother at keybase.io yet (but I could imagine installing a cert in her mail client for her). Maybe they have a sweet spot there and I am willing to accept I just don't yet understand who fits. But I don't think I'm that special, and I use gpg happily (and efficiently) every day.
If you came late in this thread or somehow still believe keybase.io equals rolling your own system, sokrates wrote a good description of what keybase.io does lower in this thread: https://news.ycombinator.com/item?id=7465349
The big assumption keybase.io seems to challenge here is that your online identity doesn't consist only of your public key.
I assume that he means they are reinventing keyservers (e.g. http://pgp.mit.edu:11371/, and the web of trust for verifying authenticity of public keys), not the crypto itself.
GitHub took a good, hard tool, git, and created a new way for its users to communicate: Pull Requests, GitHub.com repos.
Keybase is taking a good, hard tool, pgp, and creating a new way for its users to communicate: usernames, social account proofs and Keybase.io hosted pubkeys instead of keyparties and keyservers.
Github didn't invent pull requests, and that it seems to be perceived by some as if that was the case is IMO one of the big problems with github, as it serves to create a lock-in like effect (I have encountered projects that didn't have any non-proprietary contact info, so I couldn't contribute my patches).
Email is a perfectly sensible way for sending pull requests, and it has the huge advantage that it's not a centralized service that you need a special account for, any email provider will do. Hell, you even can send pull requests via snail mail if you want to.
First, I explicitly was not talking about sending patches, but about pull requests. You can actually write an email that says "please pull from git://foo.example/project topic-bar" or whatever, that is something quite different from sending mails with patches inside.
Second, this is not in any way about github necessarily doing something wrong, but about its users doing something wrong in making it into a central quasi-monopoly. If you do offer non-proprietary ways for submitting patches, that probably goes a long way - but the way github is used by its userbase (that is, people just assume you have a github account, and don't invest in non-centralized solutions anymore because github is so easy, ...) leads to there being projects that don't have that option anymore, so I actually can not contribute, and in that way, github does get in the way.
The problem is not so much the individual who happens to be hosting some project on github, the problem is the centralization and monopolization that happens when too many people do that.
Also, yes, I do understand the individual motivation for using github, because it has some short-term advantages, but you maybe should not ignore the long-term consequences. The problem is that github's UI being more convenient does not technically depend on github's centralization (technically, github is completely unnecessary for solving the problem), but it is what github uses to build its monopoly. Let me sketch out a technically different solution that would be equally convenient with no risk of monopoly abuse: How about we define a machine-readable open format for pull requests, assign it a MIME type, and then just have git itself or some local git UI (of which there obviously could be multiple different ones, open ones as well as closed ones) registered for handling that MIME type on your system. Suddenly, you could simply use your existing mail account in order to send such a machine readable pull request via email to anyone at any other mail provider (probably with a single git command or UI mouse click?), and they could with a single keypress/click in the mail client start processing/reviewing the pull request. People could host their repos whereever they want, including on their own server, and among the providers possibly could be github, but there would be no risk of monopolization, everyone could use their preferred UI, their preferred git hoster, their preferred mail provider, ..., without that being a hurdle in any way whatsoever. Now, one reason why that does not get developed, I would suggest, is because "github is so convenient".
My point is: There is nothing wrong with making things more convenient, but it would be a good idea to think about ways to make things more convenient _without_ building monopolies, if only because those tend to be highly inconvenient in the long run.
Git is hard because there are a thousand workflows to accomplish similar tasks. Github picked a few flows and rounded the edges and corners. This provided great value.
With gpg, there are already fewer workflows, and there aren't as many sharp edges as git, existing keyservers simply don't have rounded corners ;].
Keybase seems to rely on existing systems for trust anchoring (Twitter, Github...) as well as using existing cryptosystems for doing the heaving lifting (OpenPGP). If Github didn't reinvent the wheel because it's all Git, how did keybase.io reinvent the wheel by being all OpenPGP?
Its not all OpenPGP: it reinvents the web of trust part of OpenPGP instead of integrating with it.
A more 'OpenPGP way' would've been to add a new uid to your OpenPGP key for each service (github/twitter/etc.), and have the 'service' (i.e. github/twitter/etc.) sign that uid on your key.
Except that a lot of people's first experience with Git was through Github. I would say that Git might not have been as popular without Github rather than the other way around.
Keybase.io is very much rolling their own system. I think that answers the question.