In the past year and a half I’ve written a few times about an encrypted email app we built at Black Chair called Parley. Parley, at this point, is essentially dead: the service has been in “pre-beta” for about 7 months, and we haven’t made any significant changes to it in at least 5. As it stands, I consider it an impressive accomplishment for our company, but it needs quite a bit more work before being ready for prime-time and it is unlikely to see those changes without a significant cash injection. (Basically, we chose a horrible intersection of the consumer space for a bootstrapped project: email software is very difficult to get right, encryption is very difficult to get right, they are both even more difficult to get right on mobile platforms, and—even worse—general consumers are not feeling any pain due to unencrypted email. We need to target businesses, and that’s an entirely different kettle of fish.) I’m not crazy about taking on investment for this sort of project (or rather, I’m incredibly picky about who we might take on as an investor) so Parley is basically on the shelf for now.
However, we’re still extremely passionate about software built around end-to-end encryption, and we learned a lot of valuable lessons—both in business and in technology—which we’ve been eager to put to good use. Business-wise, we’ve learned that “minimum viable products” mean something entirely different when it comes to encryption software, and we’ve learned that “ship early, ship often” doesn’t work the same way in the world of installed apps (as opposed to web apps). We’ve also learned that keeping things incredibly small and simple, with the tightest possible set of features, is even more important for bootstrapped encryption projects than any other bootstrapped project (essentially, because encryption itself is such a large and complicated feature that you can’t reliably tack on much more without inappropriately increasing the scope). Tech-wise, we learned:
- Kinda like #1, but different: building apps for multiple devices is harder when encryption is involved. Ideally an email client should sync with the server, but things like marking a message as read on one device should also mark it as read on any other devices where the user is logged in, in real-time. None of the current solutions for real-time data or offline sync specifically consider the encrypted use-case, and some of them are difficult or inefficient to use that way.
- Searching and filtering data is a lot harder when the server can’t read it—you need to do everything client-side, or arrange a division of labour between server and client which leaves you with the appropriate trade between what the server is allowed to see and what the user is able to do.
- All of the cross-platform code problems related to encryption (see #1) also apply to email protocols, aka IMAP sucks. We used context.io to help us get Parley out the door, but that was (understandably) an unpopular choice among privacy conscious folks, because we were giving a third party access to their (obviously heavily encrypted, but still) data.
#5 is email-specific, but #1-4 apply to any projects requiring a “blind/untrusted/zero-knowledge” server. There are several great projects of that variety coming out lately (Turtl was on the front page of HN this week) and at least one excellent framework for them in Crypton, but we’ve been working on our own version of both (a zero-knowledge app and a framework for zero-knowledge apps) that we think nails each of those problems (with the exception of #5) in a better way. We think the app addresses some of the business problems we ran into with Parley, too. I don’t want to say too much more until they’re ready, but that should be happening within the next month or two :)