malgorithms

oh, great question! I wish I'd been clearer in the post.

Encrypted messages waiting for others are stored on Keybase servers. But they're encrypted only for the sender. The important requirement of this protocol is the removal of extra human steps, especially the ones before composing a message. The only thing a person should have to do is (a) write a message and (b) maybe tell the recipient it's waiting for them on keybase.

It's the worst to ask someone for their number or email before you get to compose a message.

There are still computer steps, however, and Keybae hides them from you. If you post an encrypted message for foo@reddit, then you sign a statement to yourself that foo@reddit is an intended recipient. When foo@reddit proves herself by announcing a key, your own client verifies the announcement and rekeys the content for her, assuming her key proof matches your signed assertion. This is no work for you, although it does require that one of your devices comes online. If they try to get to the content and all of your devices are off, they'll see a message that the original sender needs to come online before it's available for the first time.

The story with phones will be even better, as they're easier to reach through push notifications.

As with most large data encryption, this is performed by rekeying a symmetric key. So you can leave a huge attachment for foo@reddit and you don't have to download/upload the data all over again just to make it available.

As for spam prevention...we're still discussing. We obviously don't have the ability to study message contents. At the very least, we will need to have easy/clear blocking features

OP here! I had to trim the post down for brevity, but I thought the HN community in particular might be interested in the API side of things.

Undocumented in the post: you can invent channels for app-to-app communication from the JSON API. For example, it's possible with Keybase chat to have a program posting encrypted messages for another person or program, without cluttering up the visual chat interface.

Also - to test chat we've cut the invitation requirement. You should be able to try the app without anyone inviting you.

> Aging, too, has conventionally been seen as a trait dictated by evolution. Organisms have a lifespan that creates opportunities to reproduce, the story goes, without inhibiting the survival prospects of offspring by the parents sticking around too long and competing for resources.

Can someone with more bio expertise explain this theory to me? I've heard it said before, but it doesn't seem right to me. Some species disperse widely, and the offspring end up far from their parents, not really competing for resources. Wouldn't such species evolve quickly not to age, if possible? Similarly, wouldn't it be far better for non-migrating species not to age but instead evolve to migrate when old?

It seems intuitive to me that keeping an old body from falling apart takes great resources / evolutionary focus, and there are diminishing returns the further out the age. e.g.,., if a species were only 1% likely to make it to old age T in the wild, then it would be hard to select for traits that led to it being in good shape at that age.

Internally (I work at Keybase) we use it even more for the opposite. We do use it for secrets, but very often we put public info into KBFS we want to verify.

As an example, a number of us use it to address pain points around SSH. I keep this: /keybase/public/chris/keys/ssh.txt (you can see them on keybase.pub/chris/keys/ssh.txt ), and I keep all my known hosts as a reference in another file (that one in my private directory)...so when I'm SSH'ing to a machine from a new one I never have to say yes to connecting to a fingerprint I haven't actually verified. If I don't recognize a fingerprint then in turn I contact the appropriate party using Keybase, get a confirmation, and then add it to my file.

I'm bringing up SSH because we're thinking of making SSH public keys an important part of Keybase and curious if others share the same pain point. You mentioned a bunch of team uses and wondering if this was part of your use too.

Author here. Seeing some of the discussion go down on Twitter, I feel maybe I should explain further the "white supremacist" example in the post. (one tweet at me: "So now you can hide the fact that white supremacists are sending you money? F!@#ing weird example.")

When I shared a draft post with some friends, a lot of them had an ah-ha moment, so I was hoping for the same from others. I was trying to illustrate 2 privacy concerns around the graph Bitcoin exposes: (1) accidental associations and (2) exposing the people you transact with to each other.

In the blog's hypothetical, you're not receiving money from some asshole because you're collecting Klan dues from him. Rather, you performed some public transaction with a stranger. For example, maybe you sold him some tickets. An external observer of the graph who knows he's a dangerous character may start applying high odds that you, too, are a dangerous character, since they don't know why he sent you money. This would suck. And, second, this character who sent you money may also be learning things about you. Since you sold tickets to a local show and mailed them to him, (1) he's likely to live near you, and (2) he knows your return address. You really don't want him seeing that you're sending money to causes he opposes. If so, he might show up at your door.

The goal was to clear up this misconception that a private cryptocurrency is there to protect criminals. This is especially important if you'd like to post a static address on a profile.

Oh - it was an encrypted message to the OP. Here's something general: BEGIN KEYBASE SALTPACK SIGNED MESSAGE. kXR7VktZdyH7rvq v5wcIkHbrvAOc8o HtD9ll30QZYRrt1 63n5tVSjvbZwtwt nQVqdDHEZIYWqWk 57rCih2L43U8D3v uDU7bYeatPFXDSw ZikNjVdebkJILFR kJOj6IN4D9bYNmB i2nHNFWj4btITlY zaRLkk6i76FyoyS K2Bq54fZpCtrDLQ 2FONdETOnbaI0ic FvHxWlsrpGVrdNs wSVZpOWekpe0eVy YV4z1lt7ONQ4Qo2 p3cX0bRLsKiIWHX B667fNFKpAEqXxU W93RkSAvfjXBvFX zkPRUCfcAFReAQz 6nEzbsy4YfQ7m01 iEvaCvMqXgEZTOx 8F9GoqyQ6gnHfHP lG9Si8v2LNP048x F1Y3oqxh1OEaJai IjpB67iffOBo00. END KEYBASE SALTPACK SIGNED MESSAGE.

You can read this by piping into: `keybase decrypt` :

BEGIN KEYBASE SALTPACK ENCRYPTED MESSAGE. kiZ8aa8yNOPC2nP QD3QM6XxeDcurpU PZqSleTgKxgp9sd hCuooQmObarwJ3s nyWrixKOA2h8EWj 6ngTHMGf1nOnrwq 2hjkFzgNR2q2bcZ AMxPfhM5vvYEPHy HoWuLF9LYW6TQJH LLaUBL3twPV9KIw PH2WWv3PrfelwWs dWaCwzBoqmn7cWr 16bbzXP9ZJDOaRY w4JSZnRFi8Mr5zX 3LxleA9zhQKlmJj nasIyzHkP24aoB1 veAhsE0LqJCsr2r RZFuWr50FeNcpa8 vLBtRm9wwhAVlfW nnauBjDcchJGv9d 2oyhAy3b8dNCenU 4DUTEzKBQPjtnII gIEBjtppdRQrBHe cYzVCypxUolosZU w5uCDr6x1Z6ctZv vXCPwK8Fnm9QZdT KmUozJ1h6BTkd7j xRgtUWykZSVMKW9 xE15Eu5DeCLndt1 lcjFElqty7c4C6p lNIxD6MYEOeUaBq JTPikwIwPle6M80 DLxDSopyfst9zTa mJjdgw56w1bajI4 Ovzd9iHkY2o4vns jOBYmXCfoy6LI4X A3yw4DEjuGbuuj2 HXJgkbbSsxrJPKD rzZVjeWBtE6C61G cFPEAWTyWqiX17Z 5t2EPAT20T0pFGH aZBoaHnHA0McNO0 VrOS0I8Ng0Wb5CI jqrgAGTg1OGzT0U kWbm7wyXLUYfY0r tFhxwI7FanJJG63 FDFkJWc4eYlu9uI lEztervxw7pD1UL vifMFDamuFOdjEx fwSOeqO4ArDWvhl qlJy354q01KIe5E klgbuGQNRI7eaoG D01QNSWoWO7sPlQ wEkt0725b4el3Ik C7wMeF4JPRyIsEH erMb44uoqscmCKL Oq7uBB8S5U7Smsq HFfT5rnIyD43uoW Qad9j0nmPtzZODd BrTARreGT2xSxrI LRk2U01wYdYCjQZ SmlO2h2bC4ZhlcC M1JrligKAfVaeBB RLO7Oq1MAgPtT73 CGVU8c4gkvmFWAN wUC7gYivwSnKFIc IzkmMh1xdLOOoAz mPqc2plpeFOb1xU 69BYLOLY7yKSu9u qMIz5pfyH27jqe2 qcBr7ZYJnHbIEIR MEFhalnBNMYa4V6 v2xHIM17APMK4KF HMXTr6zZkzWjzaO 4v3da0FBXtOmSdw 5vyGg63adgKJfvv 2ZJ9pGCwr0EtbE0 Udq8ViuoxLdWLdS Cnia8CzkMYVZykN 0NTawBLIdLfkdS9 lkvbKdSnLTXPRO1 KO64hsp5KqthaWC rsGxnSVuPiNIYGw NNsbCoMLRhwlbjU QjrZlm5IvGXS8Xv 2BvaRPEvdCx2tKl FHe8MMgs0OCxuA7 qsTTJVr7ygjbEsX 8I0zq98SQRwPKct JO2igBY28Hdtevl o4B3qJar7cHxWAF 01keedd12iQ2s7g 1vAcePHMykUtGS8 wc1FmnsoPXPoaC3 2pOaC2h2TmLTjsB UbEKUWaQoqLuzAt H4WvBbfaG0Py1Uf 0tCn1lDfjBwoUyu Aw9hxHKLwsnFvG7 6YFPThbUAJXRkWX UkMFJGGDYB12U4O uPhgrXCOj0wyfk0 cM2LdHr8UUAvitv lEctZt35tsk7Gs3 gcnzMXFZry0YUlz HEwdmxxyge4hHvk lfbkVn8teR5ij3K aVW7cmVK8Hen7wG Uxnjdq4RbiYCvj9 Dh7MdZ9EeNAiKky TiR2Qdab5T3SBWO w7mo7AZSenrKlk9 2pdRYrorpfBXb6N UpNJX8dIDY3oKpi AT38U20c0XIhAsT rm8KD5FxwwKaOLb IRk7s6G9qxrR0JR 6JWCQss2MRlnHok Q9spNDl5ZP8h1mw moskVQG8NUoAtad XrNlwNhiPzgYahc sR3RwaduCxoItPI q1APP6bpvIXLA80 NHk1T3IRfbjoLAx KjWfLIvw2A6qMCs MLuEOCLttVOOyyf yb6tTcsgCeaPZ07 rBVIF6qQiNAVx6U SHNHiaCejEV7HaS nRJR8IgMQbkx7t1 r4o5ZCUtyjFd6Qk j3Dymz0vYmUsxLm YC88Ra84XXzzJs0 sQBnzzL7f4loH54 6Pl8wKtakQGiBHs YPg56A0QsV8rEkg Sa18oSmp5DDW5Sh c4FrnEq71ZjrAtB l26ZvEwHTfwl4Ok 5yzP9plzR4UXeJL PIsGDAs0OTnS4fd jtI4lDct1tiscY2 6ji2I4hSHxnThTd Q12xf6PruOeD6Va z067mlUxOlAxBbP AbIYzBNtCIfT3zN hXjGvaTRVO1PQ1e mCK6AEYASAK7m49 hXZbdV6yJ6Speli cwIfwwLePYZIYd1 Ce1gqim3TlsRdZo dmJV0FrlaOskSo7 PGEAOuKnC9JUvYu lloBwrrHjYcm1XY txS4luyzC39mDvc w2pbLUrk4OWNQ1n ikN0g3cFjsnuTvI cY9dqifkVnQbBos HoGRvfSOqBFFeM0 JdfYumZrhhtr0X1 93rDHsnYJVgXgEX BVVMTlK4MNGxrMU v5CJ1EiUlpPr9W4 8raCvgjMOzaY16H 7SljrVKXxNfIRRC VDXcCzY3ugncD7E 2CKKh1kc3xWZXSF RTFNVVR6t5SQV6s LnPrYV8Ypv4uyJI Qf1Xn8ExBGjdmGV QWHUpfDZkDywX4V b0VuuTrDBGErymO F9qjY8w0BBObeb2 r8RgSxnpu3cctif 1yrCL533anB0KkV TczvdwT1qdrghna PFpJg4MNAIVbPrz ZcTE4IQIkCb5PJt yLDnasbph4dodcv UIflf8m7mCmFArA gMdhfzvFNdTTkIG 4AHdK5PMNBLBori VEb0BD7QvoMizJB fkubxMk144i6PYw D9CBeRUSlWCC5Dj TMrH3LbrGX. END KEYBASE SALTPACK ENCRYPTED MESSAGE.

Oh I see, sorry for not fully answering. Keybase does not merge files or anything source-control like that. In fact, if that's what you want, you can actually init a bare repo inside of Keybase and clone into and out of it. We do this all the time as we're dogfooding. It's cool that every push is signed automatically, and every pull or clone is verified.

The conflict resolution Keybase does do is simple and much like what Dropbox does. The clients will determine a winner, and the loser will be written as something like `Keybase Logo.conflicted (sjs382's imac5k copy 2016-02-04).psd` Note in this case 'imac5k' is a guaranteed unique device name for sjs382, due to the way our merkle tree of key announcements works.

By the way, the conflict resolution of a single file is one case in a fairly large list of possible conflicts. What happens if you remove a directory on one machine, but add a file to it on another? And so on. The conflict resolution flow is designed to protect you from data loss above all else.

We are testing a build for Windows that uses Dokan. Early results have been very positive. It's an important feature of KBFS that it can run on Windows.

It works to repeatedly append to a file on one machine and `tail -f` it on another. Even an encrypted file. It just works.

As for collisions, a "conflict" is handled as you would expect on file syncing services, although all conflict resolution has to be done by the clients! (Even in the unencrypted public folders, the resolution of the conflict has to be signed. And in the encrypted case, obviously the server has no idea.) This is one of the many things that had made KBFS a large and interesting project.

If you really wanted to use KBFS as a transport layer, you could avoid the conflict entirely by each device claiming a file to write to, and each one in a folder can monitor the others' files.

These 2 docs together will explain it:

[1] https://keybase.io/docs/server_security

[2] https://keybase.io/docs/server_security/merkle_root_in_bitco...

The tl;dr: Removal statements are signed into a chain of all public announcements you make (each references the last), and each link also references the root of the site's merkle tree - a tree which includes everyone's chain. The root of that tree is written to the bitcoin blockchain multiple times per day.

The simple idea is that it's a directory mapping public keys to social accounts. If I know you as a Twitter user, I might want to send you an encrypted message. Or if I get a message from you that's signed, I might want to know that you're a certain Hacker News user. If I download some source code, I'd like to know it was signed by someone who has Github account X, and write access on example.com. And so on.

Historically, a few people using PGP would do this identity mapping, at least in one direction, by posting a PGP fingerprint (of their public key) on their, say, Twitter profile . Of course, this only went in one direction. To achieve a bidirectional proof, they would also have to post a signed statement going in the other direction, too, stating they were in fact that twitter user. (Otherwise you couldn't start with a message and conclude which Twitter user sent it - multiple people could claim this.)

Keybase started as a hobby project to make these posts structured and formal for PGP users. We just wanted to make this kind of thing easier, so we made a directory to hold the signatures going in the other direction, and a reference client that would look up these announcements and verify them.

The other specific advancement is that these signatures have been put into a data structure designed to prevent the server from lying by omission or forking - a big problem that exists with historic key servers. If you remove a key, what's preventing the server from not admitting that? Or what's preventing the server from giving Alice and Bob a difference experience from Charlie and Diane?

Anyway, that was the first idea behind Keybase. To make a better directory and walk people through these proofs.

What we realized - and what has gotten us both (a) extremely smart developers to join us, and (b) funding - is that there are deeper problems beyond the identity establishment....problems that can be solved in 2015.

Those two problems are (1) pretty sucky clients for public key crypto (at least from the perspective of non-programmers), and (2) key management issues. The first is something we have experience with, as our team has worked on a lot of successful projects. And let's be clear, lots of teams could solve this, if given the resources. The second is something we feel can finally be solved thanks to mobile phones. Phones and watches and other small devices allow you to provision new keys easily, because 2 devices can be brought together. That wasn't easy in the past. All this is now possible without understanding what a key is. Or worrying about how to store and move one around safely. That's the new goal: actual crypto clients. For signing, verifying, encrypting, decrypting, and sharing.

You can read the front page of keybase.io for some more info, but it's somewhat out of date and talks mostly about PGP. This will change when our clients are further along and we're seeking more beta testers.

> "I'm not sure that I'll use the new keying system (my use case isn't very risky)"

To be clear, you'll be using this system automatically if you install Keybase on your phone or desktop. It'll just work, and you'll have a private key on that device. As you add devices, you'll collect keys. If you remove a device, that public key will no longer be a part of your identity.

If you want to use PGP on one of those devices, you can. And you can strongly connect it to your other keys, as the graphs in the post show.

This should be easier. From a "regular" non-PGP user perspective, you needn't think of this as managing keys, or adopting a more advanced key system. Instead you would just be managing your devices and installing Keybase.

That's our hope anyway. (Disclosure: I'm one of the people working on the project - https://keybase.io/chris - thanks for the kind words about the project)

Details, in case it's helpful/interesting to anyone: https://keybase.io/docs/api/1.0/call/login . Also of note, the hashing is done client side, not server-side.

Keybase is! NYC / SF / CHICAGO

We're a tech-heavy team of 12 engineers and 2 designers, based in NYC, SF, and CHI. We are hiring specifically in those 3 locations.

We love these people:

  1. Go developers; crypto experience a big plus
  2. iOS / Android developers
  3. Node / Electron / React / JS / front-end devs. We've just   begun building our cross-platform desktop app, and our website will change a *lot* in the coming months.
  4. WINDOWS SPECIALISTS (for real)
  5. Devops

We recently closed our Series A from Andreessen Horowitz, and our aim is to bring usable public key crypto to the masses. In a nutshell: open source, high quality crypto apps. Apps so easy you don't need to know what a "key" is to use them...but with all the security of real end-to-end crypto.

We like to work with product-oriented engineers: people who realize the final product is the vision; the users are who matter.

If you're interested, check out our job page: https://keybase.io/jobs

hah, I forgot about that note.

Good point - our stance was to protect from targeted code injections (by a coerced or hacked Google). But of course you're right, there's no point letting Google know at all.

I've made an issue to move font/css hosting off Google.

You laid out a number of points there, and I think some of them are indicative of what's really holding back security for the masses.

"Matching a name with a social media is the wrong way to lookup others" -- this is the one I take greatest issue with, because it's the way we know people now. All the people I collaborate with online now, I know them by those exact names. Coworkers, remote collaborators, friends on instagram, famous software engineers (whose work I might want to consume), even my own brothers... I know them by a set of these identities. This is how I know people.

To illustrate this point: if my own brother wrote me a message and posted it simultaneously on Twitter, Facebook, and LinkedIn, I would think "yeah, that's my brother." Moreover, and more importantly, if he left those posts up publicly, over time the strength of my conviction that he actually wrote the messages (and it wasn't a short-term compromise) would grow.

This works even for people you've maybe never met in real life. If hacker news user "jashkenas" announces on HN that he has a new version of CoffeeScript, I expect that's him. If he pairs it with a tweet, then I really expect it's him. The fact that this method works for possible strangers and loved ones is very powerful. Remember, this isn't just about secure messaging. If someone doesn't have any such identities, then there's always still the fallback: exchange an identifier in person.

The alternatives are so nasty -- in person meeting, coordinating enterprisey apps, and so on -- we'll never get anywhere with this kind of thing. The solution I think you are suggesting requires a lot of human effort to figure out if you have the person you want. This is one of the danger points of PKI. And one of the inconvenience points.

"Leaving people to manage their own private keys is worse for security than having them managed by others." Part of me wonders if you're just trolling. I don't understand this, and I've read your paragraph a few times. There is the confusion argument - that people don't understand how to manage them, which is a problem we're tackling. Our argument is that it's possible to build something usable (finally!) where people do in fact own their own keys.

But you go on to say "software glitches" and "updates" are dangerous for individuals who have device keys, and then suggest they'd be ok if their enterprises / social networks managed their private keys for them. In this case, you're talking about expanding the threats considerably, while still leaving client apps that need to be updated and do the work.

Yes, addressed soon. The ideal answer for 2FA in a key-per-device app isn't really the same as the normal site + Google Authenticator / Authy kind of thing.

Oh, a clarification: the Node client will be replaced by the Go version. The `keybase` command line app will be a superset of what's available in the Node client now. Sorry. So yeah - still providing those API's.

PGP support will continue, always, it's just that you won't need to have PGP on all your devices -- just the ones you use PGP on. Your PGP key will be part of a family of keys you're known by. If you install Keybase and have no idea what PGP is we don't make you get a PGP key.

By switching to device-specific keys via apps on every platform, we can solve security and convenience problem at the same time. As the blog post says, this can only work if you can bring pairs of devices together. Which has only been possible and convenient the last couple years.

Everyone should also compare monitors, browsers, and OS when saying what they got. First try: 31 / iMac 5K / Chrome. [edit: regarding browser, I don't know much about color profiling, but I do recall seeing an example of the same images being rendered in completely different colors across different browsers on the same OS. Can't find a link.]

Some noteworthy background: this was created by Petar Maymounkov, who is also known for creating the DHT Kademlia. http://en.wikipedia.org/wiki/Kademlia

Oh cool - thanks for linking to that. I actually think the Github discussion that followed on Express was a good example of how people can actually collaborate well on software. In this case it just led to resolving a misunderstanding on my part: https://github.com/strongloop/express/issues/2464

At the bottom you can see I tipped some BTC. I recommend everyone should have a little balance of cryptocurrency to throw out thank yous to project managers who take the time to explain usage. It's worth a lot to you, so you should give some back.

If you run out of invites for HN folks, email me. (I'm https://keybase.io/chris).

We're working pretty hard on Keybase. For the last year it was just 2 of us (me and https://keybase.io/max) , but some amazing people just joined the cause and we're building a much better service. Our Go client, for example, is almost on feature parity with the old Node reference client, and we've started working on a nice OSX GUI.

A lot has been written about PGP and its shortcomings, and we agree with pretty much all the points: client integration problems, usability, the WoT just sucking, key management, revocations. So far at Keybase we've attacking one of the most important problems with PKI in general, not just PGP: getting the right key for someone. But it's really only one piece.

I don't want to (yet!) give away too much of what we hope to launch later this year, but there's nothing about Keybase that's specific to PGP. Or chat - which people seem to get hung up on. We think we're in a very good position to release open source software that makes people's lives more secure and more convenient. Everything from financial transactions, chats, and releasing public software should be easy with a PKI. It's just not working yet.

Keybase is! - https://keybase.io - we're a very small team, currently just 7.

Location: NY, SF, or CHI -- preferably you would join us at one of these places. While remote is possible, we like people to be in pairs or more, whenever possible. It's more fun, anyway. We love these people:

1. Go developers; crypto experience a big plus

2. Those with platform-specific GUI experience: we're currently working on an OSX app and will be expanding to Windows, iOS, and Android soon.

3. A Node.js developer who can also do at least some front-end js/css/html. Our server-side is mostly written in CoffeeScript.

4. Designers!

If you're interested: chris@keybase.io

> If we abolish copyright, you certainly no longer have to worry about protecting those freedoms, because those freedoms would no longer exist

I think you and the poster above you likely have very different definitions of freedom. Supporting copyright is taking the stance that a reduction of freedom (to reproduce info) is worth it, in exchange for an economic incentive to invent. The world ends up with better stuff, and the inventors are rewarded.

(That is the argument anyway.)

Those who wish to abolish copyright usually either (1) think the economic argument is flawed or (2) believe that the freedom is simply more important than the economic gains. Or some blend/combo of those 2 arguments.

So I'm curious what you mean that it actually leads to less freedom.

Keybase is! - https://keybase.io - we're a very small team, currently just 5.

Location: NY, SF, or CHI -- preferably you would join us at one of these places. While remote is possible, we like people to be in pairs or more, whenever possible. It's more fun, anyway.

We love these people:

1. Go developers; crypto experience a big plus

2. Those with platform-specific GUI experience: we're currently working on an OSX app and will be expanding to Windows, iOS, and Android soon.

3. Very product-oriented engineers. This is the kind of person who'd enjoy wireframing or planning smart notifications just as much as doing either front or back end development (probably not both). Since we're pretty small, this person would do a mix of things: user interface design (very usable, but to be polished by others), actual programming, making sure everything about the site is smooth to use. I know in a lot of companies this is often a graphic designer or dedicated interface person, but from what I learned at our last project (OkCupid), I think product-sensitive developers can be the best at it.

We have yet to take any formal funding.

If you're interested: chris@keybase.io

A lot of people are doing it this way: a GPG user can join Keybase via the website, without installing any Keybase client. When it comes time to prove something with their private key (say, their twitter account), the site shows them what to do, using bash/GPG/cURL.

It's pretty straightforward if you already have a key pair / GPG installed. There's no Keybase software to run, and the site basically acts like a todo list / tutorial.

Early, while working on Keybase, I answered it here:

https://github.com/keybase/keybase-issues/issues/788

Technically, not a lot has changed. We're still just putting our own money into it. However, we just added 3 people full-time and 1 person part-time, and so our costs have gone up. I'll admit, we only did this when we got an idea that we thought could turn Keybase into a business.

In a few months we'll be launching a tangential idea - more than just a PGP key directory. This product will let you do some neat things with data backup and signed (possibly encrypted) file hosting and message spooling. It has nothing to do with email, but it requires a real PKI. I'll save the specifics for a big announcement, but the pricing model will reflect our costs with room to make money. More per gig than Dropbox and far less than Tarsnap.

Should the "business" fail, we'll be back to where we were when I wrote the above answer.

Cool, just keep in mind Keybase isn't an email client. So if your goal is encrypted email communications, you'll still need to pick a client for that. Whiteout/Thunderbird w Enigmail/Mail.app w/GPG Tools are all apps to look at for your desktop.

Keybase right now is basically just a directory. It's a different model for making sure you get the right key for the right person. As diafygi pointed out, the traditional PGP keyserver model is busted. There's no canonical ordering of key announcements and revocations, and the gossip protocol is messy. Solving this based on social accounts is our top priority. Every proof or revocation you do on Keybase is put into a chain for you, and in turn that chain is attached to our merkle tree and written to the bitcoin block chain. We want to prove everyone in the world is getting the same answer from Keybase, everything is ordered, and that we're not omitting anything.

What you then do with those keys is up to you.

Since Keybase inevitably comes up in these PGP conversations, 2 things in advance:

1. I've really been very slow in letting people into Keybase. The wait time is still 6 months (last night I was letting in people who asked back in August.) But now that we've added HackerNews key proofs, I'll let people in today who notice this post who have more than 1 karma and write "I'm HN: {theirusername}" in the request form.

2. We're not just about PGP keys. It looks that way now, and our first goal was to help solve the very on-the-record type things developers do. Which mostly requires PGP - and PGP is very good at. Signing code and commits, releasing software, etc. But sometime soon each of your Keybase devices will have a device-specific Nacl key, for example. And the process for provisioning devices is something we're taking very seriously - we'll soon have a big blog post about how public sibling key announcements will work. Here's the foreshadowing: with a Keybase account, very soon you'll be able to start with something as simple as a Twitter or HN username, and do some very cool, secure things with files and messages.

[EDIT] We are hiring. There's no specific job page because we've mostly been reaching out to people quietly, but we want help building: the Keybase client (Go), iOS and OSX GUIS (Obj-C), and the site (front end development and back end (Node)). Please reach out to me (chris@keybase) if you like the idea of working on usable security software. We are currently distributed in NYC, SF, and CHI, and ideally you'd work with us in one of these offices.