I want this project to succeed, and it seems like it's headed in the right direction.

Some thoughts, in no particular order:

The outline would be clearer with a couple of diagrams.

How do I convince my { family, non-geek friends, etc } to give up their gmail when I send them their free invite to Parley? I'm not above using FUD to win converts, but I worry that apathy, inertia, laziness, and fear of trusting small, unproven companies are non-trivial factors to overcome, even with some really good FUD.

Will this be built on standard protocols? It seems like the answer for SMTP has to be yes, because it sounds like parley will receive "legacy" email from non-parley users and be able to send (unencrypted) email to them as well. But it also seems like there's room for something nonstandard on the client side -- will this just be using IMAP+TLS to fetch the encrypted messages and then decrypt them in the client? I guess my real question is: will there be third-party clients? Is it going to work on my { linux, androis, ios, windows, etc } device?

How are you going to handle the inevitable "I forgot my private password, and now all my email is lost and gone forever, and Parley refuses to help me!" ? (Parley can't help, of course, because it's designed to be unable to recover messages...) This, to me, seems like the biggest UX hurdle. It's like offering the most secure door locks for your underground bunker that are available -- it comes with the risk that you'll somehow lock the keys inside the bunker and then be screwed. (Lame analogy but you get the point.)

> (All messages are stored encrypted, but if they are sent
> unencrypted then they are encrypted at the server, and can
> be displayed to a logged in user first.)

This makes me wonder about spam handling. The fact that (unencrypted) messages from outside the system will be encrypted at the server seems like a giant flashing billboard with an invitation for DDoS.

When using webmail to send messages, does the unencrypted message hit the server? In general, it seems like the most secure avenue would be for encryption to happen in the clients. (Including fetching PGP keys for non-parley users.)

Regarding key management, what happens when a user needs to create a new private key? Some key revocation stuff will need to happen on the server, but then there are all those encrypted messages out there too. Will those be decrypted with the old key, reencrypted with the new key, and then the old copies destroyed?

A list of the expected methods of attack and how these attacks are mitigated would be nice to see. (Mainly, so I can see how much my security depends on parley's ops team, dev team, myself, and my correspondents, respectively.) In particular, it seems like it's worth mentioning that rubber hose crypto will crack messages when used on either the sender or the receiver of a particular message.

> Everything will be open sourced in time for the beta, and we
> will have a security audit performed by a reputable firm before
> the beta period is up.

This is great. I like this about tarsnap too -- note that "Open Source" isn't strictly necessary, but "source available for inspection" is a real winner. In fact, tarsnap is IMO a great model for how to behave as a service. Colin is not perfect, and tarsnap has had some bugs and an outage or two, but it is clear you're dealing with a human and the communication and level of openness has been without peer (perhaps more open than some "open source" projects).

The other great thing about tarsnap is the pricing. I don't know if this is practical for messaging (and it would make it hard to handle the free invites), but if you were to charge something like $0.50/GB-month for stored messages and $1.00/GB for sent messages it would provide a disincentive for abuse by users, and seems like it would make pricing fairer (for some definitions of fair). I'd guess that at least for me I'd end up spending around $3-5/month, but I'm a relatively light email user. Spam of course makes it harder to charge for incoming messages.

On the flip side: make it clear how users can get their messages out and return to legacy email solutions. Because if you turn out to suck, I don't want to be locked in. (I don't expect you will suck, but it seems like the easier it is for me to get out, the less likely it is that you'll suck over the long term.)