It is actually a good idea to use https rather than your own protocol because then your network provider/government will not be able to (easily) find out that you aren't just making https requests using your browser. Useful for people living in oppressive governments as well as employees/students under restrictive firewalls. In addition to that this will get more efficient once we have http over quic.

You can also do XMPP over HTTP (long-polling aka bosh, or websockets). If people really want to add a layer, it is doable :)

Quic seems to be the UDP equivalent to TCPcrypt? Both of which should be used by default on the Internet? But why should in your examples "the authorities" care or not whether you are using a browser over HTTP(S) or any other kind of software/protocol? If any communication channel is available, it's possible to send any kind of VPN traffic through it. Bits are bits. Especially when encrypted, so the censor has no idea as to what is inside...

> But why should in your examples "the authorities" care or not whether you are using a browser over HTTP(S) or any other kind of software/protocol?

You are going to be more suspicious if you are using $protocol-specific-for-encrypted-chat than if you are just browing the web.

> Bits are bits

I agree, but this does not stop my ISP from throttling my SSH speed.

Also, IPSec.

Bear in mind that when students and employees are on their school/work network, they often have to accept the network admin's certificate authority in order to be allowed to connect to the network. So effectively, the network admin can spoof SSL certificates and MITM traffic, even if it's encrypted.

If that's part of the threat model, a layer 7 protocol can encrypt and sign the payload. Then anybody terminating the connection wouldn't be able to read and modify messages.

There are also replay attacks and probably many other issues I can't think about. Maybe some IM protocol already deals with that.

I'm no fan of XML and think its use is one of XMPPs biggest flaws, but I wouldn't pick JSON over it… with XML at least you get a lot of the stateful encoding and namespacing (eg. extensions) right in your XML library of choice, with JSON you have to reinvent all of that which is more code, more spec, etc. I'm not really sure if there is a good alternative to XML, sadly :(

Oh, I wasn't aware of these issues - thanks for the information... would YAML help here ?

No, YAML is just terrible in general :) (ahem, unhelpful strong opinion aside: YAML is way too complicated. If you think XML is over engineered, you really want to stay away from YAML)