> Keybase.io is very much rolling their own system.

It's a store (much like github) for standard PGP/GPG keys. And it provides a convenient CLI for basic tasks.

As far as I can see, it does no more rolling of its own system than Github.

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.

Not for end-users it isn't. Even for someone who knows what they're doing, it's a PITA.

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.

> Isn't gpg already a convenient cli for basic gpg tasks?

There's no way within GPG to easily determine whether you have a trust path to a given key unless you have all the intermediate keys already.

I suggest you read "Thoughts on keybase.io" (http://blog.lrdesign.com/2014/03/thoughts-on-keybase-io/), it touches the "roll your own" points as well as authentication and consequences like vendor lock-in.

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.

We're not reinventing any cryptography here - the goal is a simple way to look up and trust keys, based on known public identities. from keybase.io

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.

I heard this point. A number of times. And I'm happy to send email patches to Linux or whatever project wants them that way.

But GitHub PR UI is more convenient. At least for me and a number of other users. It also lowers the bar, making contributions more likely.

The people that would have not contributed if there was no GitHub might be wrong, but the projects get more patches. That's it.

Finally, youtube-dl is on GH, but if you send me a patch via email, I can just 'git am'. GitHub won't get in the way.

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 ;].

... wait, there's an actual pgp thing called a "key party"? Really?

Properly and usually called a key signing party. Fewer horny suburbanites, more paranoid geeks.

Yeah, key signing parties aren't that uncommon in some circles. Everybody gets together and signs pgp keys in person.

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.

See also: https://news.ycombinator.com/item?id=7465564

I was under the impression that github is popular due to it's offerings outside of DVCS (bug tracker, discussions, documentation etc).

To me that makes it seem even more so like keybase. The core of the product is there but it's environment it was makes it special.

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.

It was growing popular at a fast pace before Github existed, because it was to good to be true (that's why Github choose it).

I think Github helped more in creating a fresh and easy way to follow/contribute to open projects.

Look up what Linus thinks of Github pull requests

Keybase is good because it doesn't re-invent the wheel -it uses PGP.

GitHub doesn't provide a wrapper around git, though -- I'd argue it's maybe closer to Heroku than GitHub.

Github is good because it adds value and removes friction.