6 ms·

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

by kylec 13y ago

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.

oijaf888 13y ago
The changes are all pretty well documented in their git repo.
- kylec 13y ago
  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 13y ago
    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.
- deleted 13y ago
  [deleted]
tlrobinson 13y ago
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 13y ago
  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 13y ago
    There is a rest API, https://keybase.io/__/api-docs/1.0 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 13y ago
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-with-webfist.html http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-w...
- jnbiche 13y ago
  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/ https://onename.io/
  - riffraff 13y ago
    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 13y ago
      No, you're wrong. It's entirely decentralized. Have a look at the spec: https://github.com/onenameio/onename 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 13y ago
      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.
  - 13y ago
malgorithms 13y ago
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 13y ago
  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.
- fredgrott 13y ago
  good Job, that is the info I was looking for..really good work..keep it up!
- kstrauser 13y ago
  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 13y ago
awalton 13y ago
> 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 13y ago
  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.

by kylec 13y ago

oijaf888 13y ago

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

kylec 13y ago
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 13y ago
  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.
deleted 13y ago
[deleted]

tlrobinson 13y ago

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 13y ago
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 13y ago
  There is a rest API, https://keybase.io/__/api-docs/1.0 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 13y ago

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-with-webfist.html http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-w...

jnbiche 13y ago
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/ https://onename.io/
- riffraff 13y ago
  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 13y ago
    No, you're wrong. It's entirely decentralized. Have a look at the spec: https://github.com/onenameio/onename 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 13y ago
    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.
- 13y ago

malgorithms 13y ago

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 13y ago
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.
fredgrott 13y ago
good Job, that is the info I was looking for..really good work..keep it up!
kstrauser 13y ago
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 13y ago

awalton 13y ago

> 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 13y ago
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.