18 ms·

Surprisingly short text for how long it sets up an analogy with little value. The problem with XMPP has always been that it is too extensible with too few guar

Surprisingly short text for how long it sets up an analogy with little value. The problem with XMPP has always been that it is too extensible with too few guarantees in interoperability. You'll know what this means if you ever set up OMEMO over 3 different client implementations. It also does too much, anything from Kafkaesque (pun intended) persistent pubsub to content labels. The quality of clients is simply not good enough, so most XEPs end up in specialized variants of clients or proprietary implementations (Facebook, GTalk, EA Origin) that lean more on ejabberd's scalability than other XMPP features like federation. Also, XML is not a good serialization format, and some of the requirements in the protocol are pretty exotic and not trivial to implement in a lot of languages. Like setting up TLS on an existing connection (plus the absolute refusal of the XMPP WG to allow on-connect TLS). JSON over websocket or HTTP are just better at reaching a wide audience of developers.

eat_veggies 5y ago
The reason that they needed to set up such a complicated analogy is because they needed a way to justify a hand-wavey fitness function of "extensibility/modularity" instead of the much simpler and more useful "does this thing actually survive?" Despite (or, as you argue, because of) its adaptibility, the answer to that question is empirically "no."
zanny 5y ago
If XMPP and Matrix were based on the same protocol stack arguments to keeping XMPP this whole time would have made sense. But they aren't. Matrix is http and json while XMPP is tcp and xml. Protocol extensions to xmpp have added http transports - but thats just wrapping non-http requests in http and making processing harder. I think a good comparison is X11 vs Wayland. X11 was retrofitted with all the functionality Wayland has natively - "why switch" is a legitimate question. But we will see in the next 20-30 years how the maintenance burden of X protocol legacy means we will see any new development using Wayland because its so much easier to do. In the same sense, chat apps will probably favor Matrix over XMPP because of the protocol maintenance burden - even when drop in libraries exist that implement XMPP, the inherent complexity makes them buggier, slower, and requires a lot of developer nuance to get right and its all due to legacy cruft you have to accommodate on an old standard. Its also like how more modern kernels stopped trying to be Unix compatible. Trying to meet the POSIX standard in the 21st century is kinda a waste of effort when a lot of it is unnecessary. The model is sound, its just adhering strictly to the eccentricities of it is just unnecessary headache.
- Gigachad 5y ago
  I was impressed at how easy it is to work with the matrix protocol. While playing around I was doing it all interactively in bash using curl. Want to read the latest messages? Curl the sync url. Want to send a new message? Post a small json object. It’s actually easier to use by hand than IRC which requires holding an open connection and quickly responding to pings. It becomes a little harder when end to end encryption is on but you just import the library they supply for almost every language and then e2e becomes transparent.
  - justaj 5y ago
    Though, ironically, as per your example, there is no library for it in Bash as far as I know.
  - nayuki 5y ago
    > I was impressed at how easy it is to work with the matrix protocol I think you were interacting with Synapse, the Matrix homeserver implementation, which is why you had an easy time. But I can't imagine the work done by Synapse to sync up with other servers is easy - and that's what I would consider the real protocol.
    - Gigachad 5y ago
      There are two protocols. The Server-Server protocol, and the Client-Server protocol. Both are "real". I was using the Client-Server protocol which synapse implements but other servers would implement exactly the same HTTP protocol.
  - jeroenhd 5y ago
    I've tried to set up some Matrix projects. The Client-Server API is easy to work with, but as soon as encryption is involved, things start getting messy. Many libraries have a hard time working right with E2EE enabled, because suddenly you need to keep track of all manner of things that aren't always documented well. I tried to hack E2EE in by using Pantalaimon [0] but running that on a server with the necessary management capabilities is very tricky and doesn't do cross signing, so I've come to the conclusion that it's effectively useless for my use cases. Every now and then I check back on the current state of E2EE in libraries and it does seem to be improving. Hopefully the entire process becomes easier next time I get the time to work on my proof of concept code. [0]: https://github.com/matrix-org/pantalaimon https://github.com/matrix-org/pantalaimon
tannhaeuser 5y ago
> XML is not a good serialization format Indeed, but here we're talking about a text format for human-human communication, something that markup languages (SGML, XML) were made for.
- sascha_sl 5y ago
  in my experience (working with academic data, JSON-LD), being aggressively semantic and adding namespaces to your format very rarely results in out of the box machine interoperability, and picking the right format out of a bunch being offered is always extra complexity on the side of the developer. but most of the time you'll likely be writing code specifically for one source of data. this leads to such standards having a shadow de-facto convention-based standard (e.g. everyone on the fediverse plays nice with Mastodon, despite ActivityPub allowing for things to be different). if you need it, just versioning your schema is imo a much better experience for developers
  - tannhaeuser 5y ago
    > adding namespaces to your format Granted, in the case of XMPP (but I'm no expert here) they might have overused namespaces with all those protocol extensions (XEPs) using their own NS. XML namespaces are one of the few additions on top of SGML and might've looked like a good idea at a time when many new vocabularies were expected, but they're controversial even among those who introduced them. Eg consider the following key quote from [1]: > On the one hand, the pain that is caused by XML Namespaces seems massively out of proportion to the benefits that they provide. Yet, every step on the process that led to the current situation with XML Namespaces seems reasonable. [1]: https://blog.jclark.com/2010/01/xml-namespaces.html https://blog.jclark.com/2010/01/xml-namespaces.html
salawat 5y ago
>XML is not a good serialization format I have never seen a good justification for this attestation that isn't some variation of "you're not accommodating the optimization I want to do that is orthogonal to rendering this binary representation into a persistent representation suitable for long term storage or transmission to another system". Even the great XML/JSON flamewar ended up with the same exact ecosystem of tools being implemented for both encoding schemes. XPATH/jq JSON schema, XML Schemas, etc... It's all encoding. There isn't good or bad; there's different, and works with what I've got with no additional work. That's it.
- jcranmer 5y ago
  One of the particular issues I recall hearing someone talk about with XMPP is that it uses XML in a way that makes it hard to use existing libraries--I believe XMPP basically relies on an unclosed XML document that keeps getting appended to, so you need to have strong partial parsing guarantees that's unusual for XML formats.
  - riedel 5y ago
    Actually removing some stuff from XPath, could give guarantees while parsing partial files. That things get ugly sometimes if XML documents aren't complete, doesn't mean that other encodings are automatically better. People should care about some good hedge grammars for extensible formats instead of getting political about that stupid encoding. There should be sth beyond current XML standards and libraries but please make it not be JSON.
  - defanor 5y ago
    That's indeed a common complaint, though streaming XML parsing is not that uncommon, and there's even a common algorithm/API for that--SAX [1]--supported by multiple libraries; otherwise parsing even finite but large documents (e.g., Wikipedia dumps) would require a lot of memory. [1] https://en.wikipedia.org/wiki/Simple_API_for_XML https://en.wikipedia.org/wiki/Simple_API_for_XML
    - duskwuff 5y ago
defanor 5y ago
> too extensible I don't see how it's a problem, except for: > with too few guarantees in interoperability ...Which indeed makes life harder. As mentioned elsewhere in the discussion, there are compliance suites, and capabilities and feature discovery, but the clients are indeed quite diverse, and sometimes it's hard to know what to expect from them. > XML is not a good serialization format I personally find it more suitable than JSON for many purposes, including extensible IM, for a couple of reasons: namespaces help to avoid conflicts, while the data model itself is more convenient for general data encoding since it's straightforward to encode sum types in XML (where a tag corresponds to a constructor), unlike in JSON (where there's a few ways to achieve it, though with JSON-over-HTTP that part is usually only done on the top level and goes into HTTP query). Maybe I'd prefer s-expressions to XML for an IM, but not JSON. > and some of the requirements in the protocol are pretty exotic and not trivial to implement in a lot of languages. Like setting up TLS on an existing connection (plus the absolute refusal of the XMPP WG to allow on-connect TLS). I wouldn't call that one "exotic": STARTTLS is used by a few other common protocols, and allows for opportunistic TLS; easily usable with common libraries (OpenSSL, GnuTLS) too. There's XEP-0368: SRV records for XMPP over TLS [1] for direct TLS connections though. [1] https://xmpp.org/extensions/xep-0368.html https://xmpp.org/extensions/xep-0368.html
- azalemeth 5y ago
  I've never understood why XML gets so much hate outside of the context of the browser. Yes, it's verbose but fully featured parsers are everywhere and it seems far easier to include a random (base-64'd) binary blob in place if required as opposed to JSON. This is an area I know little about -- I'd love someone more knowledgeable to educate me.
  - IanCal 5y ago
    I think it's partly down to being exceptionally verbose for simple tasks. Dealing with extra empty text nodes, namespacing, etc. JSON for most simple use cases is just "dump kv, load kv". I'm not sure I understand the issue with base64 in JSON? Have I misunderstood the point there?
jeroenhd 5y ago
I don't get the XML hate, to be honest. Everyone who drops XML to make it simpler to use eventually re-invents most of XML. I find typing YAML to be much better than typing XML, but when it comes to serialization, I honestly don't see why JSON is that much better. To solve interoperability, there are three or four JSON schema standards and sometimes extensive written documentation just to explain the types of fields and when they can occur. Now I need to find out which type of JSON an application uses (does it always use UTF8 or does it break the standard? Which version of the JSON Schema does it use? Is it using a schema at all? What happens when "$ref" appears in the content body? How should I deal with duplicate keys?) and how to properly encode it. It's the quick & dirty way to serialize data, and that's great for messing around with prototypes and getting started quick, but terrible for business critical applications and public-facing APIs. All serialization formats are stupid and messy in some way but I think XML gets a bad rep because of the defaults many parsing libraries picked (and the vulnerabilities they introduced). Protobuf and friends are probably a much better serialization system for chat messages. I don't see why developers fear XML so much. I think it has to do with the fact that everything is built by web developers now. Sockets have been replaced by sockets and concise protocols have been replaced by messy HTTP requests. I wonder how long it'll be before ISPs start blocking any traffic not directed towards port 80/443.
- nerdponx 5y ago
  All of these complaints also seem like valid complaints about XML, except the thing about duplicate keys. Also as far as I know, there is only one "JSONSchema", and it has a clearly defined version scheme. Are there other JSON Schema standards that I'm not aware of? I'd be interested to see them.
- tormeh 5y ago
  JSON seems to have better parsers than XML, and XML is more verbose. XML has comments though. That said, I think they're more or less equivalent. I hate YAML, though. Awful awful language. Surprisingly complex, and whitespace sensitivity in a language that's templated all the time? Must be the work of the devil. JSON > XML >>>> YAML, IMO.
  - 5y ago
dwaite 5y ago
> Also, XML is not a good serialization format, and some of the requirements in the protocol are pretty exotic and not trivial to implement in a lot of languages. Like setting up TLS on an existing connection (plus the absolute refusal of the XMPP WG to allow on-connect TLS). JSON over websocket or HTTP are just better at reaching a wide audience of developers. "StartTLS" behavior is pretty broadly pushed for across the IETF. It usually goes hand in hand with SASL support in protocols like IMAP, SMTP, and XMPP. This is really done for three reasons: 1. Detection via SRV with alternative 'secure' protocol versions requires twice as many DNS lookups 2. It makes it far more likely a client/server will ignore the text on avoiding insecure fallback. 3. It makes it harder for someone who wants to do introspection of traffic to do so cheaply by blocking the standard secure ports. Rather than multiple ports, the trend has been toward requiring TLS now that TLS certificates are something that can often be automated for free. IMHO took considerable push-back to get a cleartext version of HTTP/2 approved.
dathinab 5y ago
> XMPP WG to allow on-connect TLS) Wait what, since smtps STARTTLS is quite old I though it's by now well known that _any_ form of late TLS is a massive security vulnerability... Some form of transport layer security not being the default and starting late would for me on itself enough of a reason to exclude XMPP from a lot of things.
- MattJ100 5y ago
  I'm not aware of any vulnerability in XMPP due to the use of starttls. If you (or anyone) can prove otherwise, I'd be happy to see that. We can do coordinated disclosure across projects via the XSF.
  - sascha_sl 5y ago
    There is no attack surface because the data exchanged before the upgrade is mostly superfluous. I always felt like the refusal in the WG to add a dedicated TLS-only port in the spec was more feeding someone's conception of niceness than anything else. Happy to see it has become de-facto supported by now though. I tried writing a client in the late 2000s with .NET TlsStream and it was not a great experience.
  - dathinab 5y ago
    If any data which can potentially be exchanged before STARTTLS can affect the connection establishment in any way (except simply failing it) then there is a problem because of MITM attacks. If there is nothing like that then there is no point to have STARTTLS. Idk. if that is the case for XMPP. Note that what matter is what can be send, not what is send as a MITM attacker can modify anything. But even if not, if there is a risk of an implementation being affected by anything send by a MITM attacker impersonating a server it's an problem. Like attacking vulnerabilities in XML parsers. Either way, I have not time to look at the protocol, but STARTTLS is security wise generally a bad idea. Even if it does(?) work ok for XMPP.
    - MattJ100 5y ago
      > If there is nothing like that then there is no point to have STARTTLS. I agree that there is really no benefit to have STARTTLS with modern TLS implementations (e.g. now that we have SNI everywhere), but this was not entirely the case last time the XMPP core specs were revised. However there are multiple benefits to be gained from switching, and that is a change already in progress for some time. I don't doubt that the next revision of the XMPP RFCs will reflect this.

eat_veggies 5y ago

The reason that they needed to set up such a complicated analogy is because they needed a way to justify a hand-wavey fitness function of "extensibility/modularity" instead of the much simpler and more useful "does this thing actually survive?" Despite (or, as you argue, because of) its adaptibility, the answer to that question is empirically "no."

zanny 5y ago

If XMPP and Matrix were based on the same protocol stack arguments to keeping XMPP this whole time would have made sense. But they aren't. Matrix is http and json while XMPP is tcp and xml. Protocol extensions to xmpp have added http transports - but thats just wrapping non-http requests in http and making processing harder. I think a good comparison is X11 vs Wayland. X11 was retrofitted with all the functionality Wayland has natively - "why switch" is a legitimate question. But we will see in the next 20-30 years how the maintenance burden of X protocol legacy means we will see any new development using Wayland because its so much easier to do. In the same sense, chat apps will probably favor Matrix over XMPP because of the protocol maintenance burden - even when drop in libraries exist that implement XMPP, the inherent complexity makes them buggier, slower, and requires a lot of developer nuance to get right and its all due to legacy cruft you have to accommodate on an old standard. Its also like how more modern kernels stopped trying to be Unix compatible. Trying to meet the POSIX standard in the 21st century is kinda a waste of effort when a lot of it is unnecessary. The model is sound, its just adhering strictly to the eccentricities of it is just unnecessary headache.

Gigachad 5y ago
I was impressed at how easy it is to work with the matrix protocol. While playing around I was doing it all interactively in bash using curl. Want to read the latest messages? Curl the sync url. Want to send a new message? Post a small json object. It’s actually easier to use by hand than IRC which requires holding an open connection and quickly responding to pings. It becomes a little harder when end to end encryption is on but you just import the library they supply for almost every language and then e2e becomes transparent.
- justaj 5y ago
  Though, ironically, as per your example, there is no library for it in Bash as far as I know.
- nayuki 5y ago
  > I was impressed at how easy it is to work with the matrix protocol I think you were interacting with Synapse, the Matrix homeserver implementation, which is why you had an easy time. But I can't imagine the work done by Synapse to sync up with other servers is easy - and that's what I would consider the real protocol.
  - Gigachad 5y ago
    There are two protocols. The Server-Server protocol, and the Client-Server protocol. Both are "real". I was using the Client-Server protocol which synapse implements but other servers would implement exactly the same HTTP protocol.
- jeroenhd 5y ago
  I've tried to set up some Matrix projects. The Client-Server API is easy to work with, but as soon as encryption is involved, things start getting messy. Many libraries have a hard time working right with E2EE enabled, because suddenly you need to keep track of all manner of things that aren't always documented well. I tried to hack E2EE in by using Pantalaimon [0] but running that on a server with the necessary management capabilities is very tricky and doesn't do cross signing, so I've come to the conclusion that it's effectively useless for my use cases. Every now and then I check back on the current state of E2EE in libraries and it does seem to be improving. Hopefully the entire process becomes easier next time I get the time to work on my proof of concept code. [0]: https://github.com/matrix-org/pantalaimon https://github.com/matrix-org/pantalaimon

tannhaeuser 5y ago

> XML is not a good serialization format Indeed, but here we're talking about a text format for human-human communication, something that markup languages (SGML, XML) were made for.

sascha_sl 5y ago
in my experience (working with academic data, JSON-LD), being aggressively semantic and adding namespaces to your format very rarely results in out of the box machine interoperability, and picking the right format out of a bunch being offered is always extra complexity on the side of the developer. but most of the time you'll likely be writing code specifically for one source of data. this leads to such standards having a shadow de-facto convention-based standard (e.g. everyone on the fediverse plays nice with Mastodon, despite ActivityPub allowing for things to be different). if you need it, just versioning your schema is imo a much better experience for developers
- tannhaeuser 5y ago
  > adding namespaces to your format Granted, in the case of XMPP (but I'm no expert here) they might have overused namespaces with all those protocol extensions (XEPs) using their own NS. XML namespaces are one of the few additions on top of SGML and might've looked like a good idea at a time when many new vocabularies were expected, but they're controversial even among those who introduced them. Eg consider the following key quote from [1]: > On the one hand, the pain that is caused by XML Namespaces seems massively out of proportion to the benefits that they provide. Yet, every step on the process that led to the current situation with XML Namespaces seems reasonable. [1]: https://blog.jclark.com/2010/01/xml-namespaces.html https://blog.jclark.com/2010/01/xml-namespaces.html

salawat 5y ago

>XML is not a good serialization format I have never seen a good justification for this attestation that isn't some variation of "you're not accommodating the optimization I want to do that is orthogonal to rendering this binary representation into a persistent representation suitable for long term storage or transmission to another system". Even the great XML/JSON flamewar ended up with the same exact ecosystem of tools being implemented for both encoding schemes. XPATH/jq JSON schema, XML Schemas, etc... It's all encoding. There isn't good or bad; there's different, and works with what I've got with no additional work. That's it.

jcranmer 5y ago
One of the particular issues I recall hearing someone talk about with XMPP is that it uses XML in a way that makes it hard to use existing libraries--I believe XMPP basically relies on an unclosed XML document that keeps getting appended to, so you need to have strong partial parsing guarantees that's unusual for XML formats.
- riedel 5y ago
  Actually removing some stuff from XPath, could give guarantees while parsing partial files. That things get ugly sometimes if XML documents aren't complete, doesn't mean that other encodings are automatically better. People should care about some good hedge grammars for extensible formats instead of getting political about that stupid encoding. There should be sth beyond current XML standards and libraries but please make it not be JSON.
- defanor 5y ago
  That's indeed a common complaint, though streaming XML parsing is not that uncommon, and there's even a common algorithm/API for that--SAX [1]--supported by multiple libraries; otherwise parsing even finite but large documents (e.g., Wikipedia dumps) would require a lot of memory. [1] https://en.wikipedia.org/wiki/Simple_API_for_XML https://en.wikipedia.org/wiki/Simple_API_for_XML
  - duskwuff 5y ago

defanor 5y ago

> too extensible I don't see how it's a problem, except for: > with too few guarantees in interoperability ...Which indeed makes life harder. As mentioned elsewhere in the discussion, there are compliance suites, and capabilities and feature discovery, but the clients are indeed quite diverse, and sometimes it's hard to know what to expect from them. > XML is not a good serialization format I personally find it more suitable than JSON for many purposes, including extensible IM, for a couple of reasons: namespaces help to avoid conflicts, while the data model itself is more convenient for general data encoding since it's straightforward to encode sum types in XML (where a tag corresponds to a constructor), unlike in JSON (where there's a few ways to achieve it, though with JSON-over-HTTP that part is usually only done on the top level and goes into HTTP query). Maybe I'd prefer s-expressions to XML for an IM, but not JSON. > and some of the requirements in the protocol are pretty exotic and not trivial to implement in a lot of languages. Like setting up TLS on an existing connection (plus the absolute refusal of the XMPP WG to allow on-connect TLS). I wouldn't call that one "exotic": STARTTLS is used by a few other common protocols, and allows for opportunistic TLS; easily usable with common libraries (OpenSSL, GnuTLS) too. There's XEP-0368: SRV records for XMPP over TLS [1] for direct TLS connections though. [1] https://xmpp.org/extensions/xep-0368.html https://xmpp.org/extensions/xep-0368.html

azalemeth 5y ago
I've never understood why XML gets so much hate outside of the context of the browser. Yes, it's verbose but fully featured parsers are everywhere and it seems far easier to include a random (base-64'd) binary blob in place if required as opposed to JSON. This is an area I know little about -- I'd love someone more knowledgeable to educate me.
- IanCal 5y ago
  I think it's partly down to being exceptionally verbose for simple tasks. Dealing with extra empty text nodes, namespacing, etc. JSON for most simple use cases is just "dump kv, load kv". I'm not sure I understand the issue with base64 in JSON? Have I misunderstood the point there?

jeroenhd 5y ago

I don't get the XML hate, to be honest. Everyone who drops XML to make it simpler to use eventually re-invents most of XML. I find typing YAML to be much better than typing XML, but when it comes to serialization, I honestly don't see why JSON is that much better. To solve interoperability, there are three or four JSON schema standards and sometimes extensive written documentation just to explain the types of fields and when they can occur. Now I need to find out which type of JSON an application uses (does it always use UTF8 or does it break the standard? Which version of the JSON Schema does it use? Is it using a schema at all? What happens when "$ref" appears in the content body? How should I deal with duplicate keys?) and how to properly encode it. It's the quick & dirty way to serialize data, and that's great for messing around with prototypes and getting started quick, but terrible for business critical applications and public-facing APIs. All serialization formats are stupid and messy in some way but I think XML gets a bad rep because of the defaults many parsing libraries picked (and the vulnerabilities they introduced). Protobuf and friends are probably a much better serialization system for chat messages. I don't see why developers fear XML so much. I think it has to do with the fact that everything is built by web developers now. Sockets have been replaced by sockets and concise protocols have been replaced by messy HTTP requests. I wonder how long it'll be before ISPs start blocking any traffic not directed towards port 80/443.

nerdponx 5y ago
All of these complaints also seem like valid complaints about XML, except the thing about duplicate keys. Also as far as I know, there is only one "JSONSchema", and it has a clearly defined version scheme. Are there other JSON Schema standards that I'm not aware of? I'd be interested to see them.
tormeh 5y ago
JSON seems to have better parsers than XML, and XML is more verbose. XML has comments though. That said, I think they're more or less equivalent. I hate YAML, though. Awful awful language. Surprisingly complex, and whitespace sensitivity in a language that's templated all the time? Must be the work of the devil. JSON > XML >>>> YAML, IMO.
- 5y ago

dwaite 5y ago

> Also, XML is not a good serialization format, and some of the requirements in the protocol are pretty exotic and not trivial to implement in a lot of languages. Like setting up TLS on an existing connection (plus the absolute refusal of the XMPP WG to allow on-connect TLS). JSON over websocket or HTTP are just better at reaching a wide audience of developers. "StartTLS" behavior is pretty broadly pushed for across the IETF. It usually goes hand in hand with SASL support in protocols like IMAP, SMTP, and XMPP. This is really done for three reasons: 1. Detection via SRV with alternative 'secure' protocol versions requires twice as many DNS lookups 2. It makes it far more likely a client/server will ignore the text on avoiding insecure fallback. 3. It makes it harder for someone who wants to do introspection of traffic to do so cheaply by blocking the standard secure ports. Rather than multiple ports, the trend has been toward requiring TLS now that TLS certificates are something that can often be automated for free. IMHO took considerable push-back to get a cleartext version of HTTP/2 approved.

dathinab 5y ago

> XMPP WG to allow on-connect TLS) Wait what, since smtps STARTTLS is quite old I though it's by now well known that _any_ form of late TLS is a massive security vulnerability... Some form of transport layer security not being the default and starting late would for me on itself enough of a reason to exclude XMPP from a lot of things.

MattJ100 5y ago
I'm not aware of any vulnerability in XMPP due to the use of starttls. If you (or anyone) can prove otherwise, I'd be happy to see that. We can do coordinated disclosure across projects via the XSF.
- sascha_sl 5y ago
  There is no attack surface because the data exchanged before the upgrade is mostly superfluous. I always felt like the refusal in the WG to add a dedicated TLS-only port in the spec was more feeding someone's conception of niceness than anything else. Happy to see it has become de-facto supported by now though. I tried writing a client in the late 2000s with .NET TlsStream and it was not a great experience.
- dathinab 5y ago
  If any data which can potentially be exchanged before STARTTLS can affect the connection establishment in any way (except simply failing it) then there is a problem because of MITM attacks. If there is nothing like that then there is no point to have STARTTLS. Idk. if that is the case for XMPP. Note that what matter is what can be send, not what is send as a MITM attacker can modify anything. But even if not, if there is a risk of an implementation being affected by anything send by a MITM attacker impersonating a server it's an problem. Like attacking vulnerabilities in XML parsers. Either way, I have not time to look at the protocol, but STARTTLS is security wise generally a bad idea. Even if it does(?) work ok for XMPP.
  - MattJ100 5y ago
    > If there is nothing like that then there is no point to have STARTTLS. I agree that there is really no benefit to have STARTTLS with modern TLS implementations (e.g. now that we have SNI everywhere), but this was not entirely the case last time the XMPP core specs were revised. However there are multiple benefits to be gained from switching, and that is a change already in progress for some time. I don't doubt that the next revision of the XMPP RFCs will reflect this.