Congrats on the progress made so far. I'm eager to see how things shape up.
Would love to see a community project analogous to this one develop in the e-mail space since too many users find PGP to be cumbersome, despite some very nice implementations. Bitmessage and I2P's bote are both very interesting, but the prior project needs more experienced security people working on it (and some serious refactoring), and the latter suffers from the perceived issues of the "darknet" (not an issue for me, but...).
Would love to see a community project analogous to this one develop in the e-mail space since too many users find PGP to be cumbersome, despite some very nice implementations.
We're on it! https://parley.co will be entering pre-beta later this week. Maybe not technically a "community project" because it's being built by a company that is at least partly motivated by profit, but the whole thing is BSD-licensed so people can do whatever they want with it.
Great! Yeah, community would be ideal but a small company like yours is definitely wonderful, as well. As long as it's open source, it's fine by me.
I see you're building on PGP, which has been historically confusing for non-tech folks, but I look forward to see what you've come up with to counter that confusion.
A couple of issues:
1. Not sure if you'll be using the same server/TLS cert for your actual web-based e-mail sender, but I got a giant warning on Android (Kindle Fire running Chrome for Android) about the certificate being invalid. It's probably the fact that you need to host the intermediate certificates on your site (i.e., the chain of trust is "broken"). If you are hosting them, then it might be this issue:
http://www.unrelatedshit.com/2011/10/21/positivessl-not-work...
2. Again on the https, have you considered upgrading to TLS 1.1, or 1.2? You'd be able to offer ECDHE for forward secrecy, among other advantages. But you may have reasons for sticking with 1.0.
3. Are you vulnerable to SSL stripping attacks, like Moxie Marlinspike proposed? You are redirecting http requests to https.
Again, you may not be using this server for your actual registration, but just fyi.
One more suggestion: you may want to simplify the pricing. Do you really need 6 different categories? I'd try to eliminate at least 1, and ideally 2 or 3. Three categories may be the sweet spot (I think there's actual empirical research underlying this, but don't have time to search for citations). For a (non-scientific) summary of this, see:
http://thinktraffic.net/most-common-pricing-mistake
Good luck, and feel free to e-mail me at my username @ gmail if you need a beta tester.
Thank you very much for the feedback! We won't be using the same server/cert for the API (though it does make calls to the API for registration), but have had to move the website server around a couple of times already since setting up the cert and it's likely that I cocked something up. I'll look into it ASAP.
We are going to simplify the pricing, at least for the time being. Our beta is going to be more of a pre-beta, and completely free. Supporters will be able to pre-purchase a professional plan at less than half price, but otherwise we still have a lot of kinks to iron out before we feel comfortable charging for Parley (details will all be announced Thursday).
If you want in on the pre-beta, you can either sign up for the mailing list or check back at https://parley.co on Thursday :)
Would love to see a community project analogous to this one develop in the e-mail space since too many users find PGP to be cumbersome, despite some very nice implementations. Bitmessage and I2P's bote are both very interesting, but the prior project needs more experienced security people working on it (and some serious refactoring), and the latter suffers from the perceived issues of the "darknet" (not an issue for me, but...).