XMPP is good, great even, but it has the same issue as email where you could interface with someone not using OMEMO or whatever your encryption scheme is and it would fall back to plaintext.
The story is not quite the same for XMPP. For example, with XMPP you can determine ahead of time whether or not a contact has OMEMO. And clients configured to only use OMEMO won't "fall back".
The fallback has to be client dependent. With E2EE the server can't decrypt messages. So there's no way for the server to decrypt the message to "downgrade" the channel. The client is also the node responsible for encrypting all messages for all recipients so it has to know if any of those recipients haven't done a key exchange.
Yes. It's client-dependent for all other systems too. For example Signal's end-to-end encryption only works if both parties are using Signal.
For XMPP the difference is that there are multiple E2EE clients to choose from (see https://omemo.top/ ). And if someone chooses to use a none E2EE client, you still have the choice whether to communicate with them without E2EE, if that's acceptable to you in the specific context (not all conversations demand E2EE).
Roster/conversation capability (server holding message until recipient comes online) is a basic extension to XMPP. I don't think I've ever used a Jabber server not supporting it, and all the popular clients support it.
Yes. Same thing, same feature. This is what "conversation" mode is, also known as message archive management, or XEP-0313 (a standardized extension/feature of XMPP).
reply