Live data from Hacker News

Introducing Keybase Chat

keybase.io

111–120 of 201 posts

Re: Introducing Keybase Chat

#111
post #97
post #90

This is the last time I spam a Keybase thread with invite codes :) https://keybase.io/inv/6953921e2f https://keybase.io/inv/637bfd5d42 https://keybase.io/inv/20be67f672

Do you have any more? Looking for an invite :)

Here are some more if anyone wants one.

https://keybase.io/inv/579179852b

https://keybase.io/inv/f6062cd09e

https://keybase.io/inv/dd1b318f03

Re: Introducing Keybase Chat

#115
Hey Keybase, I have a question for you guys:

What if we launch our own apps and websites that would allow users to claim they are X on website Y. Do you have a way for them to use their public/private key pair from their keybase clients, to sign these claims?

I do not necessarily want these claims to be publicly available to everyone on website Y. I want them to be privately transmitted between website A and B, so people can't be tracked between domains.

Re: Introducing Keybase Chat

#118
post #8

Earlier quoted context omitted.

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 Keyb…

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…

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.

Post reply on HN