[kylec]

I like the idea of Keybase.io, but I would prefer to use it in a way in which I don't have to trust them at all. As it stands, you need to install their command-line tool and have it directly manage your GPG keychain. For that, I'd prefer to have a platform-neutral tool that's been independently audited and managed by my OS's package manager rather than their keybase-installer tool which seems to want to update very frequently with who-knows-what changes.

[malgorithms]

While we like being #1 on Hacker News, bad (good?!) timing is what earned us this spot.

It will be the case very soon that you can push your key to Keybase and prove all your identities, without ever installing the client the OP dislikes. Technically, you can already, we just need to put together very explicit instructions and documentation that's different for each kind of proof. By ugly necessity, what it takes to prove yourself on twitter is different from github is different from DNS, etc. Documenting the API was our priority coming into this week.

Later this week the site will have very specific instructions on how to prove your identities (even the complicated ones) simply from your shell plus GPG.

Then those who care can verify all those proofs with a script, in a language of their choice. No Node or NPM needed for any of it.

There was some discussion below about "trusting" the Keybase server's definition of the public key that comes back. The goal here is to remove that trust. Software of your choice can download a Keybase user's keys, the links to their proofs.

[kylec]

Excellent! I'm glad that we're on the same page here. Thanks for making the service, once the single point of trust (your client) is removed I should be able to fully recommend it to everyone I want to communicate with.

Just a thought: I like how you walk the user through the steps you took to prove that the owner of the private key signed the tweet. I suggest you also provide the appropriate commands to perform the verification ourselves as well. The client does this, but for users operating without it it'll be very useful.

[maxtaco]

This feature is now live on keybase.io. You can prove Twitter, GitHub or Web site identities without posting a secret key or installing our installer. We give you a (rather long) pipeline to run at your shell.

[fredgrott]

good Job, that is the info I was looking for..really good work..keep it up!

[kstrauser]

So, am I (as #3000-something in the beta queue when I signed up for it) any nearer to having an account I can start testing? :-)

[mikegriff]

Send me a mail, I have a couple of invites available.

[tlrobinson]

It looks like you can just do this to import a key into GPG:

    curl https://keybase.io/[them]/key.asc | gpg --import

It won't show you the identity proofs though.

[kylec]

Interesting, I didn't know that. I still need some way to produce the verification files/tweets for my own account, though, and currently the only way to do that is with the client. (Maybe it works in the browser if you upload your key, I did not do that for the same reason the post author didn't.)

[mey]

There is a rest API, https://keybase.io/__/api-docs/1.0

Additionally, I have used GPG and their website with javascript based crypto in some cases without using their NPM app. I believe their goal is to get other client implementations out there on the public api.

[epaulson]

I also like the idea of Keybase.io, though I wish it was based on something a little more decentralized. The unfortunately-named WebFist looks cool:

http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-w...

[jnbiche]

Have you checked out OneName? It runs on the Namecoin blockchain, so it's quite decentralized.

I've not actually tried it yet, but it looks pretty damn cool.

https://onename.io/

[rakoo]

Then again, why not use namecoin ? They (we ?) have a spec with what format your records should look like:

https://wiki.namecoin.info/index.php?title=Identity

Basically, there's a whole id/ namespace where you register your personal information, and there's a d/ namespace where you register domain names (akin to DNS). Onename is the same except they use i/ (they haven't even tried to discuss it and basically did it all from scratch to start clean)

The major problem is that you basically need a namecoin client to interact with the data... unless you use dnschain [0], which act as a HTTP-to-Namecoin and DNS-to-Namecoin bridge. Try this:

$ dig @dns.dnschain.net otokar.bit

$ curl http://dns.dnschain.net/d/otokar

both are my personal domain, delivered to you through plain old protocols. The last one even works in your browser !

Come and join us, this is actually the future. Oh and by the way I'm id/rakoo.

[0] https://github.com/okTurtles/dnschain

[voltagex_]

>You have asked Firefox to connect securely to wiki.namecoin.info, but we can't confirm that your connection is secure.

[itistoday2]

Looks like they didn't pay protection money to a CA. Huh.

[larrysalibra]

And unlike keybase's "it's complicated so it must be good" proofs, onename's proofs are easy -> add a pointer from your onename namespace to your social media property and a pointer back to onename to prove you own it. No need to generate signatures that break when anything changes.

https://onename.io/larry https://keybase.io/larry

[riffraff]

please correct me if I'm wrong, but I think this is not really decentralized. It's a single authority that owns a namespace in namecoin and is giving out sub-names. It's decentralized in the same way a twitter account is.

[jnbiche]

No, you're wrong. It's entirely decentralized. Have a look at the spec: https://github.com/onenameio/onename

Anyone running a full Namecoin node (ie, anyone running Namecoin client) can register an identification.

OneName is providing a convenient web portal to this key-value store on Namecoin, so their business model is somewhat analogous to Blockchain.info's (or perhaps they have another business model in mind, who knows?).

[vertex-four]

Nobody can own namespaces. They're "just" acting as a middleman for buying names in Namecoin in a namespace they've defined themselves, but anyone could bypass them and buy their own names in that namespace.

The annoying thing is, we already have a namespace for identities, it's standardised and documented on the wiki. They came in and defined their own namespace for no good reason.

[awalton]

> platform-neutral tool that's been independently audited and managed by my OS's package manager

Your OS's package manager is simply wrapping up whoever else's software in a nice pretty bow and releasing it. The only veracity it has is that the person who put the bow on it signed it. It's highly unlikely they did any kind of "independent auditing" or managing beyond writing some script to build the software.

Or worse: if Debian is an example, they'll say "I don't understand this code, therefore it's not useful", comment it out, and ship horribly broken software to you.

At the end of the day, you have to trust someone. Whether you trust keybase.io or not is entirely up to you - liz setup an incredibly tedious blog post to basically say just this.

[rlpb]

Part of what distribution-managed trust establishes is that it puts all distribution users (of that particular distribution) in the same boat. This is incredibly useful for verification purposes.

If I cared, I could even cross-verify across distributions by comparing their source tarballs.

> Or worse: if Debian is an example, they'll say "I don't understand this code, therefore it's not useful", comment it out, and ship horribly broken software to you.

The other point of view: they fix software so that it is useful, and I can easily have an integrated system. For the one problem you point out, there are hundreds (or probably even thousands) of useful integration patches that distribution users take advantage of every day, without even realizing it (and those suitable for upstream projects generally get pushed that way, too).

If you don't like distributions, then don't use them. And have fun with that.

[oijaf888]

The changes are all pretty well documented in their git repo.

[kylec]

How do I know that the changes keybase-installer is downloading are the same as those in the repo? I'd have to do a lot of legwork every single time I update just to be sure. Better to use a tool I can verify once and use forever, or better yet, not use one at all.

[maxtaco]

Hopefully the pace of changes will slow down once we arrive on the correct core feature set and we sort out the bugs. An earnest thanks to HNers and others for being such great alpha testers BTW.