This is cool. One thing that keeps me from using Slack, &c is that I don't trust my information to be stored on their servers. Keybase's combination of private keys and open source tools and protocols makes me comfortable with your server-side storage.
Your post does a good job describing what is stored in a readable format on your servers. One thing I didn't understand is where the data sent to users not yet on Keybase is stored. It sounds like my client is responsible for storing this unsent message, either locally or on Keybase's server encrypted for myself, and occasionally querying the DB to see if the target user exists and re-encrypting it. Is that right?
Finally, any thoughts on spam prevention for this protocol?
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
Thanks for expanding, and I wish you luck on the spam prevention. We often have conversations in the office about implementing a cost-based anti-spam system[1] for email, but I think a lack of universal usage kills that idea before it can begin. Keybase may be in a position to implement it before the protocol and user interfaces have ossified. Something to think about.
I find this stuff fascinating. Deciding not to interview with you guys because I didn't want to move remains one of the biggest "what if"s of my career so far :)
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
This immediately jumped out at me as a potential problem with the system. I think you had better get jumping on it quickly. Preventing abusive messages is much easier if mitigation is built in from the start.
What prevents hundreds of spam messages hitting a new user as soon as they sign up? An automated system could create a spam message for every github user account (just as a way to get likely signup identities) and keep a client running and they would be delivered to new users as soon as someone verifies themselves. A group of people could target one individual so that they are flooded with unwanted messages upon joining.
Your post does a good job describing what is stored in a readable format on your servers. One thing I didn't understand is where the data sent to users not yet on Keybase is stored. It sounds like my client is responsible for storing this unsent message, either locally or on Keybase's server encrypted for myself, and occasionally querying the DB to see if the target user exists and re-encrypting it. Is that right?
Finally, any thoughts on spam prevention for this protocol?