Keybase's new Proof Integration Guide | Hacker News Reader

Keybase's new Proof Integration Guide

keybase.io

152 pointsxdrixxyz25 comments

Oh, wow, this jumped the gun for us. We weren't expecting to announce this until next week! It's also in a bit of a draft form, and we expect to improve this integration guide as we add partners.

Keybase's view: identity on the Internet should not be just about Twitter, Facebook, and the other superpowers. Your membership to any site might be meaningful to other people, whether that membership is to something small like a phpBB forum about motorcycles, or something big like LinkedIn or Etsy. Often, the smaller the community, the more meaningful and close-knit membership is. And the more that community might want access to secure tools such as Keybase. If you're on the forum, you might _really_ need to reach out to another user of that forum, securely.

It might be a good time to mention that Keybase is looking to hire an Identity Evangelist[1]. This would be someone with a tech background (i.e., from the HN crowd), who has great presentation skills and experience, and who wants to help other sites and apps integrate with Keybase.

[1] https://keybase.io/jobs#evangelist

Why does Keybase allow a single remote identity to link to multiple Keybase accounts, but does not allow one Keybase account to link to multiple remote identities (on the same service)? If I run multiple Twitter accounts, I don't see why I shouldn't be able to link them all to my Keybase profile.

I think this might be a side effect of the Keybase UI, not the service itself. If you interact with the APIs directly and look at the JSON, you can see that at a high level the proofs are a dict, with each service as the key, and the value is an array aggregating several proofs. You could therefore potentially have several Twitter proofs associated with different accounts ("nametags") that could then be presented all together if someone wanted to tie all those accounts to your identity.

I only skimmed TFA, so I'm not sure what the process would be like for actually validating those proofs, but the backend datastore seems like it wouldn't have a problem, at least.

The new Proof Integration Guide explicitly says that a Keybase account can only be linked to a single identity on your identity service (but that you can link multiple keybase accounts to that same identity if you want to).

I'm really glad to see opinions like this that are strongly tinged against the centralized web, coupled with engineering work to enable more independence. Thank you.

A highlight point for me is that services should support both those superpowers and smaller entities, as yours does. Rather than isolating the open web from these entities, we need to make bridges between them so people can cross.

Totally off-topic but if someone from keybase can answer ... since keybase finally added chat history search it's only missing two features for me - responsive design(if you make the main window small then the left menu and especially contacts list don't scale and you end up with small chat and these two huge panels on the side) and dark theme.

=> Any plans to focus a bit more on GUI?

This is really cool and I really like the keybase idea, however it's really hard to get people to convert from say Telegram or FB Messenger - the features are so on-par even the lack of dark theme is a deterrant. Point being that I hope you/they implement the most commonly used features other messaging systems have in order to make conversion possible.

Keybase had so much potential for identity management, but decided to build an overly-complex invasive app (menu-bar resident app, anyone?) which never actually worked for me.

It seems that the complexity overwhelmed the team: I recently tried to add a reddit identity and even that failed.

I would really like a more limited feature set, which works reliably.

If your bar for "overly-complex" is "has a menu bar icon", your standards are far too extreme to be useful.

The client is open source; you can build just the CLI client if you want. Check out https://github.com/keybase/client/tree/master/go

Will this always require manual step of sending the proof config to Miles or is there some automation planned? (e.g. scanning of /.well-known file or something like that)

I wish Keybase has a second factor for authentication.

It does by the fact that you trust your new device on first use to be yours. You can wipe application data once you close the app if you want to go trough 2FA every launch.

Does that mean you go through an extra authentication flow to enroll the new device? Otherwise it's not 2FA, it's just telling you after the fact that someone got into your account.

Yes you have to authenticate any new devices from one of your existing devices.

Last week, I logged into Keybase from a brand new iPad without any authentication challenge from a trusted device. As far as I can tell, there is no second factor.

Did you use a paper key?

Just used username and password.

That's weird. Almost all the nodes on your graph are signed by your PGP key 'F155E778FA657400' or the paper key 'above sleep'. The rest were signed by other devices, or were the original node...

https://keybase.io/gluecode/graph

I did the same thing via browser on a new laptop. Just l/p

If you log into the website, there is no second factor. If you already trusted a device, there isn't a seecond factor either.

Logging into new devices does not ask for a second factor. I’ve verified this last week when I got a new iPad.

It requires you to trust your new iPad from another device, in addition to the password. That's 2FA.

As other comments have pointed out, devices (mobile and desktop app) do require 2FA and there's no way around that. So I'm assuming you meant the keybase.io website where you can log in with username and password.

Note that the functionality of the website is very limited. You can't access any chat messages or non-public KBFS data, for example. The most power thing you can do is resetting your account, and after that is probably using your PGP key if you uploaded an encrypted version of your private key to Keybase. If this worries you, you should turn on lockdown mode [0] to require a device to access those features.

[0] https://keybase.io/docs/lockdown/index

After forgetting my password a few weeks or so after first creating my account (I went a long time without ever trying out Keybase, because its value proposition AFAICT wasn't very interesting up until around a year and a half ago), I had Max reset my account. I was left with mixed feelings about this:

1. Extreme gratefulness esp. wrt the hands-on approach to "customer" support, but concern for the scalability of a process that require that level of manual involvement, and

2. Concerns with how easy it was to get keybase.io/$MYNAME disconnected and reconnected by the Keybase switchboard operators

... and I wondered why Keybase's proof system didn't play a part in authenticating me.

For example: Let's say I create a Keybase account, forget my password, and realize I'm not logged in on any device. If I need to reset an account that has N social proofs, wouldn't it be a good idea for Keybase to make me prove that I am who I say I am by adding/altering M of N proofs?

And on that note:

Given that you're rolling out third-party integration, how about building off OP's thoughts, so a Keybase user can configure their account to say, "You should be able to verify that $SERVICE implements the optional 2FA parts of the Keybase integration spec; please use $SERVICE as the 2FA provider for this account."

Reply on news.ycombinator.com