Earlier quoted context omitted.
Gah, HN is rate-limiting my responses. 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…
Assume for a moment that JS crypto is insecure. If you use a web client with JS crypto to bootstrap acceptance, then the majority of your clients will end up using JS crypto. If the majority of the clients on the 'network' are insecure, then what's really the point?
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.