What about Axolotl, with the addition of the server signing a hash of the master key with an ed25519 private key whose corresponding public key is shipped with

What about Axolotl, with the addition of the server signing a hash of the master key with an ed25519 private key whose corresponding public key is shipped with the app? Perhaps with a fixed 2 step "CA" trust path so each individual server can have its own signing key. The server would be authenticated to the client, but not vice versa. Clients would have to provide some credential in band, but it could be bound to their identity key after that so it shouldn't need to be done again even when creating a new session (eg. fresh connection with different server) If a server is compromised its signing and identity keys can be replaced. The DH ratchet heals the compromised session keys, compensating for the lack of an out of band key revocation mechanism. Sessions could be time bounded to mitigate the damage of clients sending with compromised message keys in between DH ratchets. Where that fails the server could reply with a message disclosing the compromise, forcing DH, limiting the damage of continuing to use the compromised hash ratchet. For additional security clients could sign all their messages with their identity key. If the server logged all of them, then it would be possible to check after a server compromise that the attacker didn't forge anything. You'd have to do something to break up big messages into chunks for UDP transport. There's a BSD licensed ratchet implementation from Silent Circle.