The white paper suggests you'll issue an HTTP request for an RSS-like object. The HTTP request will contain your public key - which could be encrypted using HTTPS and having it as a POST form parameter in the request body rather than a GET request in the URL (I think - never tested that), but that would be kind of pointless anyway, since to send you a direct message people need your public key anyway.
The RSS object returned will contain public messages, which are signed by the author, and private messages which are encrypted with your public key. Your client would use your private key to decrypt those messages. It's all the same as using GPG on emails to sign or encrypt.
The tricky bit is that the white paper suggests that the server will use your private key to only send you the private messages if you send it the right public key, so they're sort of secret unless you send it the right key which is pretty much public anyway. And, in my experience at least, when you get an encrypted message you can see which keys were used to encrypt it, even if you don't have one so you can decrypt it yourself. So anyone spying on the system could see which users private messages were sent to, even if they couldn't see the message.
I don't see any way around that. GPG encryption exposes the same information, although at least there it's more open since you're actually sending the encrypted email to those people.