<div dir="ltr"><div>Hi</div><div><br></div><div>I'm partly responsible for that long and confusing document:</div><div>  <a href="https://code.google.com/p/end-to-end/wiki/KeyDistribution">https://code.google.com/p/end-to-end/wiki/KeyDistribution</a></div>

<div><br></div><div>I'll try to answer some of the meta-concerns that are misunderstandings. Thank you all for your feedback, we are listening :)</div><div><br></div><div>Regarding Moxie's concerns about auditability by the users. To facilitate a user to enumerate all her keys in the log without having to download the entire log, we want to make each entry point to it's older, previous entry. This means a user doesn't have to rely on the Monitors to notice a key introduced covertly, they just have to rely on the Monitors to show it's running a compatible/latest version of the log (as long as the user's client queries for the user's key).</div>

<div><br></div><div>I agree that the "wingnuts" problem that Moxie touched is there, but we just want the service to be able to give proper notice to the user when she is being attacked (either because of phishing, and someone taking over her account, or because her domain expired and the new owner wants to use that email too, etc).</div>

<div><br></div><div>For the real-paranoid that wants real-life strong-identity assertions, we will try to make fingerprint verification easier.</div><div><br></div><div>Regarding the "simpler thing" model, it works too! And that's how Mailpile works as I understand it. One important difference, as other pointed out, is that this doesn't require users to do introductions every time, which is unfeasible for some usecases we would really like to support, but I'll try to be compatible with Mailpile (it seems simple).</div>

<div><br></div><div>About the blockchains. Keybase stores a copy of their STH to the blockchain! It's kind-of like a gossip channel I guess, and I think it's not a bad idea.</div><div><br></div><div>Regarding the SPAM problem, on publishing a list of emails vs a derived value (scrypt or so): It's a tradeoff of auditability and semi-anonymity. We might do it, but we want to be sure sacrificing auditability has been thought over before deciding against it.</div>

<div><br></div><div>To answer Adam's questions about revocation, whenever a new key is inserted to the log, we consider the previous one revoked. The verifiable map is simply used to show that a key is the latest entry.</div>

<div><br></div><div>Some of the other questions raised were about the usability challenges and how to communicate different edge cases to the user. It's a hard problem that needs research. We are working on that, I wish I could give a better answer, but that's the hard part of this project.</div>

<div><br></div><div>Hope that helps, and thanks again.</div></div>