1. The web crypto api was indeed made to secure communications, such as stated by the W3C on http://www.w3.org/TR/WebCryptoAPI/ (...) "Uses for this API range from user or service authentication, document or code signing, and the confidentiality and integrity of communications. "

2. Yes, you are definetly right, an detailed audit of the protocol is necessary by more than one expert.

3. Here is a short description of the basic concept: Client and server are seperated. The client software is basically what is hosted on Github. Its source code must be protected from MITM attacks of course, so it is best to ship it as standalone, downloadable application in the final release. THE CLIENT CODE WILL NOT BE OFFERED BY A SERVER IN A PRODUCTION VERSION.

So at sign up, the client software now generates a (RSA) public key pair and some symmetric keys used for (AES) encryption and integrity protection locally and encrypts it with a passphrase. The passphrase is only known by the user, but not by the server. The encrypted string is also integrity protected. It is sent to the server, stored there, and decrypted with the passphrase at login again. This way we ensure only the client software can see secrets, such as the private key, but not the server software.

Next, you have a key directory. It is signed after every modification with a secret salt which was generated by the client (and not known by the server) at signup. The keydirectory contains all the verified public keys of the user. (Protecting it from replay attacks would be worth another essay here) Now when you write messages for example, you get the public key from this directory and encrypt/sign it basically like in PGP. So the focus of this preview is not on the crypto primitives, but rather on the concept itself.

Edit: I hope this does not sound too unfriendly, I am very happy about your feedback and I promise I will look for further advice regarding the crypto/protocol ;)