3 ms·

Right, I ignored sending unencrypted emails as they can be already considered "broken" as soon as they reach Gmail. Those emails are the only ones whose plainte

Right, I ignored sending unencrypted emails as they can be already considered "broken" as soon as they reach Gmail. Those emails are the only ones whose plaintext we see for a short amount of time, but we get rid of it as soon as we send it out to a remote server. Regarding RFC-compatible PGP emails - unfortunately right now it doesn't interop well at all. The server does support sending of PGP/MIME emails, but IIRC the frontend doesn't have any code for that. Internally we try to use our own PGP Manifest format for everything - it leaks the attachments count, but it's a lot faster and easier to parse (for example during clientside search index generation that we're working on). PGP/MIME switch in the app is in plans, but we're far from implementing such thing. Client-server is all HTTPS, either over plain requests or a SockJS bridge. I've already written a non-browser client that automatically sends "onboarding" emails and forwards emails to our support system - you can see its sourcecode here: https://github.com/lavab/lavabot https://github.com/lavab/lavabot. If there's enough interest, we might even create an official CLI client for the service - I've recently suggested a native app design that might work pretty well in such use case ;)

e12e 11y ago
Thank you for the link -- I suppose it should've been obvious you'll have some use for command line tools internally, if only for automation (but automation is important, how else can my backup cron job let me know it's completed/failed? :-) Not so good that you don't (currently) interop all that well. I can understand that gpg/mime is a bit hard, and have some properties that aren't great (metadata/subject header...). As for plaintext being "broken" when reaching gmail, I suppose I've grown to be a different kind of pragmatic lately. Lets put it this way: I still enjoy postcards, and while (some) encryption is trivial (with the right tools, some of which you are building!) -- I really don't need "another messaging app" (but secure!). I need email that is easy to secure/so easy that always encrypt is useful. Then again, most of the email I send and receive go to public mailinglists -- without clearsigning, I'd have no use for your product (yet -- none of my private contacts use gpg, and are likely to move to your platform just to get it). That's not to say I'm not interested to see where you end up, and wish you all the best with your project!

e12e 11y ago

Thank you for the link -- I suppose it should've been obvious you'll have some use for command line tools internally, if only for automation (but automation is important, how else can my backup cron job let me know it's completed/failed? :-) Not so good that you don't (currently) interop all that well. I can understand that gpg/mime is a bit hard, and have some properties that aren't great (metadata/subject header...). As for plaintext being "broken" when reaching gmail, I suppose I've grown to be a different kind of pragmatic lately. Lets put it this way: I still enjoy postcards, and while (some) encryption is trivial (with the right tools, some of which you are building!) -- I really don't need "another messaging app" (but secure!). I need email that is easy to secure/so easy that always encrypt is useful. Then again, most of the email I send and receive go to public mailinglists -- without clearsigning, I'd have no use for your product (yet -- none of my private contacts use gpg, and are likely to move to your platform just to get it). That's not to say I'm not interested to see where you end up, and wish you all the best with your project!