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 :)
https://keybase.io/inv/579179852b
111–120 of 201 posts
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 :)
https://keybase.io/inv/579179852b
Earlier quoted context omitted.
Do you have any more? Looking for an invite :)
https://keybase.io/inv/1c385d4ff6
I have a lot more, message me if you want one.
111MB for the setup download (at least on Windows)?! What's in it apart from a chat app and encryption library?
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.
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…
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.
Why doesn't this seem to be in a release? The last release of the client was back in October: https://github.com/keybase/client/releases/tag/v1.0.18
We don't use GitHub releases often.