[howeyc]

Maybe I don't understand, but why even have messages retained on the server at all? Couldn't the local app keep them stored on the phone?

Also, does anyone know if they're encrypted at all. In this day and age isn't that a requirement for them to be considered private?

[k-mcgrady]

>> "Maybe I don't understand, but why even have messages retained on the server at all? Couldn't the local app keep them stored on the phone?"

People use multiple devices. People get new devices.

[schrodinger]

What if the other phone is off at the time? You kind of need a server to act as a buffer. No reason why it couldn't be client side encrypted though... iMessage does that.

[lttlrck]

the sender can do that.

[thenipper]

What if the sender is offline when the receiver signs back on? Does the message not get sent?

[Spearchucker]

You'd use a basic store/forward protocol. Sender sends message to a zero-knowledge server. If the sender has no network the encrypted message is stored locally, on the client device until the server can be reached.

Similarly, the recipient polls the server for new messages only when online. Any messages accumulated by the server since the last sync are downloaded. That's the easy part. More interesting is the key exchange that needs to take place between sender and recipient for them to exchange messages securely. The idea being that both parties each create a public/private key pair for each other, and then use each others public key to encrypt the symmetric key that decrypts messages.

Straight-forward enough. The problem here is when you want to exchange messages with Bob, you need to know that you have the real Bob's public key, and not an imposter's key. While an in-person, meatspace exchange will give you the assurance you need, that's not always practical.

Here's a bit more detail on how you might engineer the key exchange: http://en.m.wikipedia.org/wiki/Needham-Schroeder_protocol