Thank you so much for your thoughts! In order: - We will be releasing less technically-focused promotional materials as we approach the beta. If we can earn th

Thank you so much for your thoughts! In order: - We will be releasing less technically-focused promotional materials as we approach the beta. If we can earn the trust of our technical friends to do some pointing and sharing, we're more than happy to do the convincing :) - Feedback so far indicates a wide spread of platforms being used, so we're shooting for a cross-platform launch. We will use standards as much as possible, including IMAP and SMTP over TLS, but with an extra HTTPS interface for our clients to use. Since the whole thing will be open source, we would love to see third-party clients emerge, but our first priority will be getting the first-party clients to be flawless. - The forgotten password situation scares us, too. It's a really angry blog post waiting to happen. All we can really do is a) make the risk very clear and b) make the "private password" (we'll need to come up with a better designation for each password) recoverable/changeable locally, ie. once a client is successfully installed, the keyring is only encrypted using the "normal" password so we could either store the private password there too or allow the user to re-encrypt the keyring using a new private password. Part of this falls unnder the category of "UX stuff we're still trying to figure out". - Spam will be an issue, and I should have included it in the outline (I forgot, and plan to add it at some point). Unencrypted messages hitting the server will be spam-filtered before encryption. We'll have to come up with something smarter once people start sending encrypted spam. - Using the webmail feature is not the "most secure" because, as you say, PGP encryption needs to happen at the client. In the webmail scenario, the message hits the server unencrypted and public keys are sought out by the server. The rest of the time, all PGP functions occur at the client. Webmail is really just an "add-on" and we're downplaying it as much as possible because it's causing too much confusion. - I don't see how Parley can be compatible with a revoked key scenario, and in practice I'm not sure how that is different from current PGP/GPG use. Do people re-encrypt multiple GBs of data when they revoke their old key? I would recommend that Parley users in that situation download their old messages and store them however they wish, then create a new key and request that their old messages be deleted (we will try to keep backups separated by user account so that this is actually possible). As always, I'm open to any suggestions you might have, and please let me know if you think I'm understating the issue. - We'll try to put together some threat profile stuff at some point. You're right that rubber hose crypto can break Parley in a number of ways, as could the usual other deus ex machinas of security (keylogger on the client, etc). - We are huge fans of what Colin has done with Tarsnap. If we together can be half of what he is all on his own, I think that would count as a success. FWIW, we do mean "open source" in the traditional sense, at least for the clients (leaning towards MIT license), and all code will be "source available for inspection". - We're not a fan of what Colin has done with Tarsnap pricing. I mean, we like it for us but I don't want to subject "normal" consumers to that. But pricing is hard, so we're still thinking about it a lot. - Excellent point. Users will be able to export their keyring from installed clients, and all messages will be retrievable via IMAP over TLS. We'll try to make that as clear as we can without confusing less technical users. (And thanks for the vote of confidence ;) We'll try not to suck :) ) Again, thank you so much for your detailed thoughts on this! EDIT: Good point about the diagrams, too. We're juggling a few balls, of which publishing information is only one, but we'll try to get some diagrams up eventually!