Hacker News new | past | comments | ask | show | jobs | submit login

Why are people so attached to XMPP?

There was no entity preventing XMPP from thriving, if the community really wanted XMPP, we would have had XMPP everywhere.

But honestly, as someone who ran and tried to use XMPP for many years, the entire protocol was an unmaintained divided mess. And the XEPs didn't help, they felt like hacky workarounds to keep an old protocol up-to-date with the modern needs.

Matrix feels very consistent, specially in the client side. I have all the modern features one could have wanted (E2E encryption, video and audio calls, file sharing, proper synchronization across multiple devices, etc) working out-of-the-box across all my devices. This was almost impossible to achieve with the XMPP clients existent nowadays.




Weren't facebook messenger and google talk based on xmpp? I know that at least they were compatible, but in the end they removed that. Trying to force people on their own client


This is the problem - if you have a large user base there is simply no business incentive for federation. It is so much easier (and cheaper) to just build your own silo without worrying about interoperability. Plus you have the ability to monetize a closed system through ads, data mining, etc. There are so many advantages.

And people don't complain (much) because, for chat especially, they have had years of conditioning that leads them to accept (and expect) that communication with their online contacts depends on installing multiple apps from multiple vendors and sharing their data with those vendors on whatever terms the vendors decide.


And don't forget about spam. Spam becomes a problem when your system gets bigger.


Google Talk was, Facebook just had an xmpp gateway.

Google killed the xmpp momentum by gettimg scared of Facebook around 2010. and adopting the 'walled garden' approach.


Of course, app that implements it's only server API would be consistent with itself. You see, Matrix isn't mature enough to have XMPP's problems, such problems must be deserved first.

And seeing how fixated matrix zealots on JSON superiority over XML as a format, I don't think Matrix will ever mature to a point to have problems faced by real federated protocol with multiple implementations of both clients and servers.



What does JSON vs XML have with facing problems related to maturity?


I have very same impression. XMPP is basing on XML where parsing is order of magniture more complex than JSON. In lot of ways very similar to SOAP mess where you could not comunicate across different software because each of them supportet different set of SOAP extensions and good luck with communicating with web client.


> XMPP is basing on XML where parsing is order of magniture more complex than JSON

The last time I heard, there weren’t two JSON parsers that actually accepted the same language, so I’m not sure there’s an existence proof to back this statement up. :-)

XML is more complicated, but if we want to compare apples to apples, it’s only due to the white space sensitivity. (dtd, schema, etc don’t have analogous technologies in the json world, and at least xpath is a standard, unlike jq).


> XML where parsing is order of magniture more complex than JSON

You're supposed to use an off-the-shelf XML/JSON parser, not write it yourself.


Even if you don't parse it yourself, XMLs data model is usually more of a chore to consume.


XML/SGML is highly appropriate for representing rich text, though, which is the purpose of chat apps/logs. Using JSON you'd have to invent ad-hoc markup on top of JSON, loosing any advantage it may have.


Nobody uses rich text formatting, and even if they did, the message body is only a small fraction of the total protocol content.


> Using JSON you'd have to invent ad-hoc markup on top of JSON

That's basically a description of ActivityPub that wraps HTML in JSON!


Will activitypub let me do:

  <body> markdown text </body>
And ship some js to convert to html?


No, each server has their own rules what and how will they present content. Usually they accept limited subset of HTML and filter out everything else.


Where does "order of magnitude" come from? In my experience, XML parsing is about three times slower than JSON and around two or three times the size. For most complex applications, this is not a show-stopper, because the bottleneck is elsewhere.

XML was a hype in 1999, when XMPP has been invented and JSON was a hype fifteen years later. When people invent protocols they just use what is trendy in the moment.


Sure, XMPP has problems, but ZERO of them comes from using XML. Thinking that using JSON will help solve the real problems any federated protocol would face is very naive and will lead to more than a few unpleasant discoveries down the road.


fwiw, nobody on the Matrix team (or that I know in the community) thinks that JSON is somehow fundamentally superior to XML - it’s just a data encoding. More recently we’ve been using CBOR over JSON for instance. Anyone who claims Matrix is about “using JSON rather than XML” to do the same thing is catastrophically missing the point.


https://twitter.com/joepie91/status/1102888957510107136?s=19

Check this active member of the community. Also folks on this very page claim how xml consumes much more resources


XML is not popular because of JavaScript developers.

Coming from .NET, I do not care using JSON or XML, because the APIs System.Xml.Linq, Newtonsoft.Json and the upcoming System.Text.Json are a joy to use. I think the lack of good native representation of XML in JavaScript made it a unwanted choice.

Regards SOAP I tend to agree to you. Beyond the Basic profile it was a hassle to interop.


>XML is not popular because of JavaScript developers.

This could not be more false. JavaScript is built around the DOM. You can parse XML with DOMParser and query it with the same interfaces that you build your UI with. The X in AJAX is XML. The "good native representation" of XML in JavaScript is the very core data structure that JavaScript was designed to interact with.

XML is not popular because it's complex. Escaping is hard. XML bombs make it unusable in its raw form.

Fundamentally, XML doesn't give you data structures that look like the ones you use in your application logic. You have to transform your data into something that makes sense in XML, then transform it back. With JSON (and other formats) the data structures that you're given are present in almost every programming language. You don't need to model your data differently for transit or storage than you do in your application logic.


Good arguments but using DOM Api in JavaScript needs many more lines than JSON parsing and access. jQuery made HTML access bearable for a simple reason: DOM sucks :)

Average Joe Dev does not reach the impedance mismatch you mention correctly.


The DOM interface is roughly the same in almost every language. The JSON interface is almost always simpler. It's no mystery why JSON is more popular. XML never died because of JavaScript developers.


XML is extremely popular with the JS crowd, they just don't know they're using it ;) JSX (React's template language extension to JavaScript) stands for "JavaScript XML" [1], and there was E4X as an official ECMA spec for XML literals before that (though admittedly not as cool as React is, doesn't have vdom and update events, components for MVC, etc). And JavaScript was indeed invented for DOM manipulation, it's just that the DOM API simply sucks.

The whole XML hate thing is symptomatical for the staged this-vs-that discussion we endure in today's forums.

I guess there are those document representation schemes that everybody hates on, and those that nobody uses ;)

[1]: https://en.wikipedia.org/wiki/React_(JavaScript_library)#JSX


E4X was far more powerful than JSX. JSX is just a nice syntax for object construction. E4X could additionally query XML (think XPath but different) not to mention support for XML namespaces, etc.

I agree with the rest though.


I agree.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: