5 ms·

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 th

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

coldpie 10y ago
> Keybae I hope this is an internal nickname ;) 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 :) [1] https://en.wikipedia.org/wiki/Cost-based_anti-spam_systems https://en.wikipedia.org/wiki/Cost-based_anti-spam_systems
po 10y ago
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.

coldpie 10y ago

> Keybae I hope this is an internal nickname ;) 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 :) [1] https://en.wikipedia.org/wiki/Cost-based_anti-spam_systems https://en.wikipedia.org/wiki/Cost-based_anti-spam_systems

po 10y ago

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.