Very familiar with the document, but it mainly just boils down to watch-out for XSS attacks. We require SSL to deliver the entire page with no external libraries or references. His response to this doesn't really say anything. See: "WHY CAN'T I USE TLS/SSL TO DELIVER THE JAVASCRIPT CRYPTO CODE?" We need the crypto for keygen and signing and encryption, so he's missing the point completely.
To the other point made above along the same lines, the protocol is the key and you are free to choose your own client. No matter which you choose, you have to trust the source.
Our goal is to get the protocol adopted and used as widely as possible. Mass adoption is only possible if there's a web client with JS crypto, and there's no way around the need to trust the server you download it from.
If you run a hardened trustworthy client, your own public posts are still verifiable, and private posts meant for you are decodable only by you.
You would just need to make sure to send your private posts only to others that use trustworthy clients. But, because you're sending them a secret message in the first place, you already implicitly trust them.
I'll submit that because it's in-browser it's additionally difficult - very difficult - to get right, but I don't see that it's impossible.
