|
|
|
|
|
|
by maxtaco
3189 days ago
|
|
|
It would be great to see it deployed, but it solves only (1), and even so, not completely. I couldn't find it in the doc, is there a story for revocations? Part of our concern about the PGP story is that malicious servers can suppress revocations. In Keybase's architecture, we've committed to an append-only data structure, which makes it impossible to withhold revocations without being detected. In a decentralized setting, you could do something similar with a blockchain like Bitcoin or Ethereum, but for usability, it would be important to do so without requiring mobile clients to download the entire blockchain. (BTW, that draft cites Keybase as a motivation for their approach :) ) |
|
|
Yes, I know. Without Keybase this draft would probably never exist in the first place :)
> I couldn't find it in the doc, is there a story for revocations?
Yes, it supports revocation as links are stored as User Attributes (similar to UIDs).
> In a decentralized setting, you could do something similar with a blockchain like Bitcoin or Ethereum, but for usability, it would be important to do so without requiring mobile clients to download the entire blockchain.
Yes, I've been thinking about using Blockchain for that purpose but I'm waiting for something more concrete to materialize out of Key Transparency [0]. As far as I like Keybase for something so fundamental as identity I think a distributed solution would eventually be necessary.
As far as I remember you write sigchain Merkle root to Bitcoin [1], that's a good security measure. (although you may consider using OP_RETURN outputs rather than fake output addresses, that optimizes unspent transactions database on each Bitcoin node).
[0]: https://github.com/google/keytransparency/
[1]: https://keybase.io/docs/server_security/merkle_root_in_bitco...