As someone who has been working with XMPP for a long time, I can safely say that most of the criticisms here simply have no material effects in practice. Yes, an ack packet can be 19 characters long. Is that terrible?
It would be just as easy to write a post like this about JSON, Matrix and so on. Both have many warts.
But I really don't much care. No technology is perfect, and there will always be people who dislike choices that other people have made. What matters is what we do with the technology. XMPP has proven itself able to evolve over more than two decades, during which the internet and the way we use it has shifted dramatically, and yet it continues to be relevant as new people discover and adopt it.
It's unfair to describe things like multi-device sync as "afterthoughts" when XMPP was one of the first real-time messaging protocols to have support for multiple concurrent connections of the same account built in, at a time before the iPhone was released, and most people had a single device with wired access to the internet only.
Support for multi-device sync is part of the suite of protocol features required by modern XMPP implementations, these requirements are updated every year to account for the changing technology landscape: https://xmpp.org/about/compliance-suites/
I personally like the simple delivery model of XMPP compared to the "distributed database" model that Matrix pursues. I think there are use-cases for both approaches. Both XMPP and Matrix have bridges between each other and third-party protocols (proprietary and open ones), which makes any attempt to create false competition between them an unhelpful effort. What's important is that both provide openly-documented protocols with open-source reusable implementations, and (in my opinion) most important of all: decentralized open communication networks.
The problems facing the broader adoption of open networks for modern messaging are not protocol problems.
I've worked with XMPP for years, and I say it's bad and outdated. The criticisms linked are all valid, and there are good reasons it's being abandoned. Was a great protocol back when it was the open alternative to AIM.
About the XML bloat you've mentioned: The problem isn't just the wire size, it's working with it as a developer. XML is needlessly complicated to deal with in code and super painful to read when debugging. Tooling for it seems lacking too; I even found that iOS's built in XML parser was very slow at parsing large elements, with time/mem used seemingly growing O(N^2). Found that out when the XMPP-using startup I was working for decided to send all their XMPP IQ messages as just wrapped JSON payloads.
About extensions: As cool as those XEPs are, it makes for a fragmented federated ecosystem when so many basic features are extensions. It's not awful when maybe you can't send large files on one server, but when something like auth is broken...
For messaging purposes, it is absolutely identical to JSON in this regard. Once you have many existing implementations out in the wild that need to interact with each other, you'll need namespaces or their NIH analogue. And JSONs with namespaces will be just as bloated as XML.
Understand this: xml is meant to be read by computers, not humans.
> The criticisms linked are all valid, and there are good reasons it's being abandoned
It's 2022 and there is still nothing better for federated messaging.
Being sent on every connection for no reason, thrice (!)
>Once you have many existing implementations out in the wild that need to interact with each other, you'll need namespaces or their NIH analogue. And JSONs with namespaces will be just as bloated as XML.
Even XMPP, with XML, could do just fine without namespaces. The only place where namespaces are the differentiating factor in practice is <query/>'s and <x/>'s. Couldn't they just be be called <mam_query/> or whatnot? Oh, and namespaces specify the version. Like for ack's they specify the version 3 every time. But it's something that has to be (and is) clarified when enabling said acks anyway.
> xml is meant to be read by computers, not humans.
Online sources say it's meant to be both human and machine readable. It would be less bloated if it were just for machines. Seems like a generalization of HTML, which is meant to be hand-crafted in some cases.
Even if it were for machines only, it'd still need a human-friendly way to manipulate and debug with, and there isn't one. Protocol buffers have the text version for humans and the serialized binary for machines, plus the generated getters/setters for code. XML is a pain to deal with no matter how you abstract it.
JSON with namespaces would just mean another key-value pair in the dict or something. But I'm not sure why that's needed anyway.
> It's 2022 and there is still nothing better for federated messaging.
True, but federated messaging isn't in style anymore, and honestly I hardly even used XMPP. Was working on my own protocol 2 years ago that I truly believed was the best, and had a working reference impl, but had to abandon it. Got 2 jobs already.
Only if you switch to JSON the way they describe in the joke XEP https://xmpp.org/extensions/xep-0295.html where they force XML into JSON form instead of properly redesigning the messages.
I think most people agree that XMPP messages are hard to read during debugging, and this is somehow not a problem in any of the JSON-based protocols.
No matter how many times you say that, it still won't be true. A mere few minutes spent looking at the Matrix protocol and a few minutes spent looking at XMPP (if you can get past the fact that it's XML) will make that clear. Matrix is basically a case study in how not to design a federated chat protocol. It's bloated, it ignores all prior art and reinvents the wheel everywhere it can, and its excessive complexity means there is unlikely to ever be a wide ecosystem of good-quality implementations (especially of servers). Just because they made a foundation and threw around the word "standard" a lot doesn't mean it deserves to be the standard for chat protocols.
Matrix might have bad core tech, but they are one of the only groups working on the biggest issue with federation.
Tying identity to a server is insane in a decentralized environment. Decentralization is all about keeping Google sized companies from controlling things. But small companies come and go all the time, and nobody trusts them to be around in 10 years.
They aren't solving the SSL problem though. Mumble has a good solution their with their trust on first use connections. Self hosted really should ideally not need a domain name if you want individuals to host it. It should be something you can literally buy a $20 preconfigured hosting node, plug it in, and go.
Tox seems to be most promising of current ones, it just needs to fix it's mobile data use issues.
>No matter how many times you say that, it still won't be true. A mere few minutes spent looking at the Matrix protocol and a few minutes spent looking at XMPP (if you can get past the fact that it's XML) will make that clear.
Maybe judge not by reading protocol description but by trying and using said protocol, like, chatting with people a lot? With the latter approach you'll notice a very handy feature of Matrix - not losing messages.
> A mere few minutes spent looking at the Matrix protocol and a few minutes spent looking at XMPP (if you can get past the fact that it's XML) will make that clear.
You're right, Matrix immediately stands out as what XMPP should have been from the beginning.
> Matrix is basically a case study in how not to design a federated chat protocol. It's bloated, it ignores all prior art and reinvents the wheel everywhere it can, and its excessive complexity means there is unlikely to ever be a wide ecosystem of good-quality implementations (especially of servers).
Hi, I've worked on client and server implementations of both XMPP and Matrix. This is a wildly inaccurate - but unfortunately common - view of things.
It's correct that Matrix is complex to implement server-side, more complex than XMPP, and it's also correct that it does a lot of things very differently from older protocols like XMPP. But here's the thing - that's a deliberate choice and it is for good reasons, not just a case of ignorance or "bloat" like you seem to be implying.
(Sidenote: if there's one thing I've learned over the years, it's that somebody talking about "bloat" is a huge red flag that they don't have a very deep understanding of something. If you have a genuine complaint about unnecessary complexity, you should be able to point it out specifically, instead of a handwavy term like that.)
Anyway, to get back to the point... much of the complexity in Matrix comes from a single design objective that differs from XMPP: it implements decentralized rooms instead of centralized ones. That is, rooms are not dependent on a single server for their continued existence, they will remain available regardless of server availability.
This might seem irrelevant, but it solves a huge problem that XMPP has been struggling with for years, and that IMO is a major reason why its MUCs never became widespread: the problem of putting trust in a server operator for the continued existence of your community.
Every single time you create a MUC in XMPP, you are essentially betting on the continued existence of whatever server you are creating that MUC on. If it ever goes away, so does your community - and unlike with a list of private contacts, it's hard to rebuild a community. That's a tremendous cognitive overhead for starting a community! And one that most non-techies - understandably - do not want to have to deal with. Trust is hard.
Matrix doesn't have this problem because of its decentralized rooms; it doesn't matter how many servers go away, as long as the homeserver of at least one room participant still exists, the room continues functioning as it always has. That means that you create a room "on Matrix", not "on a specific homeserver". That's much easier for users to deal with.
The tradeoff is that unlike with XMPP, where you have a single authorative server for handling things like access control and moderation and membership, this needs to function entirely decentrally in Matrix - so now, the network is suddenly a distributed system that needs to handle state synchronization and everything that that entails.
And that is where the server-side complexity in Matrix comes from. It is necessary, unavoidable complexity if you want to solve the problem of "where do I put my community" in a way that actually works for regular users. It sucks, but there simply is no simpler way to solve this problem.
The reason XMPP doesn't have this complexity is because it doesn't even try to solve this problem. If the rumoured decentralized MUCs ever become a thing, they will involve similar complexity.
Edit: Also, it would be nice if y'all recognized that the priority should be to get the general public over to open comms systems, instead of constantly trying to start wars against Matrix folks. The constant loud misinformation and attacks are getting very exhausting.
> For messaging purposes, it is absolutely identical to JSON in this regard. Once you have many existing implementations out in the wild that need to interact with each other, you'll need namespaces or their NIH analogue. And JSONs with namespaces will be just as bloated as XML.
It's definitely not identical. There's one major difference, that rarely seems to get mentioned but seems to be responsible for most of the pain:
JSON maps directly to language-native data structures, but XML does not.
The reason for this is that XML distinguishes between child nodes and attributes, but in the basic data structures that most languages have, there's no way to represent this in a conflict-free manner without doing something like `{ attributes: { ... }, children: [ ... ] }`, which is an awkward structure to query.
The result is that when you're working with XML, you almost always end up with a "data API" that's designed specifically for XML (eg. classes representing nodes with getters for attributes and children), whereas with JSON you're generally working with simple nested lists and structs.
This introduces relatively much complexity in what's a "hot path" in terms of development effort - every single time you want to interact with the deserialized data (which is all the time!), you have to deal with an XML-specific data structure instead of treating it as "just another source-agnostic pile of structs/objects".
The result is tightly coupled code that requires the reader to be familiar with the specific XML API/representation being used, instead of it 1:1 mapping from the serialized data to a language-native data structure. That's not good!
While it is true that you are likely to implement a namespace-like mechanism in JSON as well, for open protocols, the difference is that the format itself does not specially define namespaces - which means that the 1:1 mapping always remains true, and it's the protocol developer's choice to eg. reserve a `children` property to contain child nodes, with the understanding that that property then cannot be used for other things anymore.
XML deserializers cannot do this; it's entirely possible for XML to exist that looks like `<tag children="yes"><subtag/></tag>`, and therefore there is no possible 1:1 mapping that a deserializer can use that's guaranteed not to make certain data inaccessible. And since child nodes are not represented as an attribute in XML's data model, you cannot expect protocol designers to avoid a specific attribute either.
Bottom line: I suspect that this seemingly small design difference has far-reaching second-order effects in how deserializers are implemented, and that that is responsible for most of the pain that people experience in working with XML.
> JSON maps directly to language-native data structures, but XML does not.
So what? It is irrelevant. In all the problems we have ever faced when creating federated chat applications on various platforms, I can't recall a single time when stream format made any difference.
For example, making your messages appear in consistent order on all of your and your chat partner's devices is a real problem. The development of the efficient strategy to achieve this has nothing to do with format, yet, has a much more visible impact on user experience. In fairness, the debate of what is better suited for the protocol development, Message Sequence Charts [1] or Sequence Diagrams [2] has more sense than debating about XML vs JSON.
I call it a "pseudostandard". When you need extensions to use it at all, and half the clients are missing just enough of them to be useless for half the users.
Plus it's confusing. You have to look through feature matrices instead of just saying "Oh this is version 4, it has everything I need".
In my experience, XMPP has rarely "just worked." Always had to find the right client for the server I was using, or at least mess a lot with the settings. It could've benefitted from being more opinionated.
JavaScript is very much a pseudostandard these days.
Most of the new stuff is invented by Google and rejected by Mozilla and Apple.
If you are in an intranet environment where you only ever target Chrome and Chrome Mobile and pretend the rest don't exist, it kinda does work like that.
> Most of the new stuff is invented by Google
...to gain even more control over what's left of the Internet. Yeah, everytime I get "your browser is not supported" after loading a shitton of CSS+JS (literally megabytes), I remember Google and their cronies like framework writers and careless site developers. Just because Google added new CSS keyword doesn't mean everyone should drop old ways of doing things.
>I personally like the simple delivery model of XMPP
The moment you ask for reliability it stops being simple. Stream Management + Stanza Ids isn't simple, and it shows - XMPP is the only thing I use today where it occasionally happens that a message isn't delivered and I'm not even notified about it.
On a side note I don't believe that this can't be fixed. Maybe if we had end clients checking directly with each other what's been delivered and what hasn't, like actual humans end up doing anyway, I believe it'd be more reliable. Besides instead of relying on the c2s-s2s-s2c cooperation chain to work, it'd rely on just c2c cooperation, giving much fewer variations to test.
Just to clarify I'm not talking about a p2p connection but rather e.g. checking the number of stanzas not with the server, but with the interlocutor's client, through the normal XMPP means, like <iq/>s maybe
I'm not really sure how to silently lose messages in XMPP these days, if you use stream management (which everyone does[*]).
The last gap I'm aware of was that if you sent a message to someone on a remote server, and the remote server couldn't be connected to, your server would generate a delivery error (i.e. not silent). But* if you went offline before this delivery error reached you, you would never see it. These days such errors are stored in the user's message archive, and available to all your clients for synchronization purposes (so all of them can see that the message failed to deliver).
So with that said, I'm very interested in hearing any details you can provide about how to silently lose messages in modern XMPP. Clients involved, steps to reproduce, etc. Then we can produce actionable bug reports.
[*]: I believe Pidgin is still a notable exception here. Notable mainly because a lot of people still use it, even though its protocol plugin development has stalled somewhat for many years (the project is still being developed, but their focus has been on core/foundation improvements rather than keeping up with changes to modern internet messaging).
>So with that said, I'm very interested in hearing any details you can provide about how to silently lose messages in modern XMPP. Clients involved, steps to reproduce, etc. Then we can produce actionable bug reports.
Conversations, draugr.de, can't really say much on steps to reproduce - it worked reliably and then it didn't just yesterday, ironically just as I tried to send the article to a friend to check out.
If I understand the two generals' problem correctly, there always is a way to silently lose messages, with any protocol, it's just that some approaches to not doing that are more reliable than others
A simple protocol for message delivery that will not silently fail: resend it (presumably with a unique identifier of some sort to avoid duplication), pessimisticly and loudly pointing out "failure" (really: ambiguity of delivery), until you get a reciept of delivery.
What the two generals problem points out for this protocol is:
1. the sender of the reciept won't be certain that said reciept was recieved
2. the message may be successfully sent before the sender realizes it
3. if communication is permanently severed, the sender may forever be uncertain if the message ever got through or not (but this can be messaged loudly and pessimistically to the end user)
This creates design problems for coordination of consensus for things like database transactions, but a chat client failing to alert to potentially undelivered messages is just bad, not merely running afoul of some fundamental law of information science.
Of course, it's always possible to successfully send and recieve reciept of a message, only for the recipient's server to suddenly catch on fire and explode before backups are made, thus permanently losing any record of said message, but that's more of a "two generals and an assassin" problem, outside the scope of the original thought experiment. It is also, hopefully, a rarer scenario than packet loss.
> Conversations, draugr.de, can't really say much on steps to reproduce - it worked reliably and then it didn't just yesterday
So it worked fine for some time, glitched one day, you presumably have done zero debugging as you have no logs or error messages to show us and somehow that means that clients "just lose messages".
> The moment you ask for reliability it stops being simple. Stream Management + Stanza Ids isn't simple, and it shows - XMPP is the only thing I use today where it occasionally happens that a message isn't delivered and I'm not even notified about it.
>It would be just as easy to write a post like this about JSON,
JSON has no namespaces, even without taking that into account it's already less verbose, it maps nicely into lists and dicts, I don't know a single JSON parser that can leak the user's IP even as an option, let alone by default (not saying there aren't any at all, just no popular ones), doing a binary version of XMPP based on JSON would take as much as switching over to bencode instead of whatever the unsupported hell EXI is. So no, you can't really write a post like this about JSON. Even if you do, it's not gonna be XML that will be proposed as a better solution.
One thing where XML beats JSON is markup. But with XMPP's unholy approach to markup, it's actually JSON that beats XML.
Namespaces address a real concern that inevitably comes up in protocols dealing with complex data and combining syntax from different standards or sources. That being said it is very easy to make half-assed solutions to the problem of namespaces, and the full-assed solution for namespaces is always a little complex and brittle, so it isn't surprising to me that most people end up going the half-assed route.
By far the most widely used half-assed solution to namespaces is in the HTML5 parser to special case svgs (and maybe other curiosities? Dunno). And if I understand correctly, that happens to be a full-assed specified algorithm that all current browsers use.
That is all in order to avoid the problems that would have come with requiring the full-assed XML namespaces in that case.
If I were a political operative, I would attempt to bog down the XML apologists on this point whenever they attempt to argue that JSON gets as complicated as XML when you try to include namespaces.
It's not the lack of namespaces that causes people to reinvent them. Using or not using namespaces is a choice you take. With XMPP it's 100% dictated by the XML mindset. There is NO reason for
to specify urn:ietf:params:xml:ns:xmpp-tls other than formalism/a yearn for bloat. There would never be a name collision without this ns and it convenes no useful info.
There's no reason for acks to specify urn:xmpp:sm:3 each time. Yes, here it at least specifies the version, but that's already negotiated when enabling acks anyway.
There's no reason why <query xmlns='urn:xmpp:mam:2' .../> can't be <mam_query .../>.
Namespaces are a choice, sometimes (e.g. in programming languages) reasonable, sometimes (in a serialization format for passing small texts around) not so much.
It is dictated by a mindset, the XML mindset in case of XMPP, and in the case you bring up apparently by the Java mindset, not to say there's much of a difference between the two
Switching to JSON over XML would solve approximately zero problems that decentralised communication protocol faces. In fact, it would only make things more complicated and less flexible.
Yet Matrix is gaining traction while XMPP is not. Maybe the key was to have funding, build and run a reference server and quickly iterate with a reference client for all major platforms.
> Yet Matrix is gaining traction while XMPP is not.
I'm curious what you base this on. Without a doubt Matrix is gaining traction. It's a relatively newer project, has some new ideas, and there is a lot of buzz around it. But it has far to go before reaching XMPP's levels of achievement - millions of XMPP-connected users via Google Talk, and popular products such as WhatsApp and Zoom built on top of it. That many of these aren't, or are no longer, interested in interoperability or federation is not a protocol problem, and I don't see Matrix solving that.
XMPP continues to be widely used by individuals, organizations and governments who want more control over their communication. Across the XMPP projects and services I'm involved in, I continue to see plenty of new users and developers joining the community.
The reference client/server is definitely a pattern I agree with you on, however. It has served Matrix well, and others too. I've been a proponent of this approach for some time, and detailed my thoughts in the "Products vs Protocols" talk/post at https://snikket.org/blog/products-vs-protocols/
>But it has far to go before reaching XMPP's levels of achievement - millions of XMPP-connected users via Google Talk, and popular products such as WhatsApp and Zoom built on top of it. That many of these aren't, or are no longer, interested in interoperability or federation is not a protocol problem, and I don't see Matrix solving that.
But these aren't the protocol's achievements either. These people have so much money they could make IRC popular.
One big goal of XMPP was federated messaging (compare to email), and I'm not really seeing it. At best I'm seeing companies building on top of it, resulting in something hardly resembling the open version. Companies are benefitting from XMPP's freedom to build their own platforms, but that freedom isn't being passed onto end users in the vast majority of cases. Because XMPP, with its amorphous nature, doesn't stand up well enough as a product on its own.
XMPP has succeeded in its other stated goals of being highly extensible and useful for derivative work, but I think that's in spite of the protocol. There are just a lot of solid implementations out there, like ejabberd (which afaik WhatsApp originally started on, and I worked with it in a startup).
After trying Matrix as a Discord replacement with a couple of different clients it was pretty terrible. My Discord usage is fairly simple but I run a community for non-technical people. Matrix UX was pretty shit between confusing clients and just the overall clumsiness. I would have loved to introduce a whole community to it but instead I went back to Discord instead.
I run a server for a non-tech community with roughly 300 members ranging in age from 20 to 65. Some of them are extremely non-technical, to the point that they say “hey Siri turn on flashlight” instead of finding the button on their phone. Every single one was able to figure out Discord in a matter of minutes and use it daily with zero complaints. I would say that’s a customer success story right there.
> Yet Matrix is gaining traction while XMPP is not
Considering the way in which Matrix spreads unencrypted metadata (even rooms and participants in the rooms, let alone chat events) as far as possible across the network, this traction is quite insidious.
Not a lot better, but in public MUCs your JID is hidden to everyone except the server the MUC is hosted on. Also MUCs can be configured to only send a limited amount of history to new participants.
For this reason I'm somewhat uncomfortable joining Matrix rooms over bridges, since it leaks my XMPP address and participation to everyone forever.
It doesn't look like Matrix has reached the point where there is any significant network effect. What I'm saying is that they are building a product, and the protocol is just one component of that product.
The key to interoperability is agreeing on standards. XMPP being about creating a proper Internet Standard and not a product is what made me choose XMPP over Matrix (also simplicity).
Not losing messages is pretty key too.
But yeah, given enough marketing you can pull anything off. WhatsApp basically doesn't support multi device to this day and is more popular than either (free) XMPP or Matrix could ever hope to be.
There's a web version but it only works if your phone is connected. So I guess the phone acts as a server then? Does that mean they found it easier to set it up like that than to make xmpp (which WhatsApp is said to be based on) reliable with multiple devices?
That is not true anymore. The latest version of WhatsApp Web can be used without your phone connected. Not sure if it is rolled out globally for everyone yet, as it was fairly recent for me (couple days now).
WhatsApp first penetrated countries where people's primary computing devices are phones, and they maybe don't even own PCs. It's not surprising that it became super popular despite its lack of multi-device support (at least until recently). Wasn't just marketing.
It is not a long solved problem if it takes a demo to prove. If it were long solved it'd be self evident. This argument wouldn't exist to begin with.
A demo is worthless if experience doesn't prove it in the long run. And I have the latter, and it doesn't prove. Yes, I know it's probably me, or more likely my friends doing something wrong. One of them restricted Conversations from running in the background for example, non-techies do all sorts of silly stuff. But then again, it shouldn't break with non-techies either. Nothing breaks with them aside from XMPP. Not even WhatsApp which is based on XMPP afaik
> Support for multi-device sync is part of the suite of protocol features required by modern XMPP implementations, these requirements are updated every year
The problems is that many of these modern features were unbelievably late.
Obviously a new user is not expected to fathom what all this means before getting started, which is why there are curated lists of public XMPP services, e.g. https://providers.xmpp.net/ and https://joinjabber.org/ and for private servers there are projects like Snikket where the server software is developed in parallel with apps to ensure a consistent feature set.
I think the decline of xmpp can be traced to the rise of text messaging and phone messaging in non-open protocols. One factor that made non-open protocols more palatable on the phone than on the desktop is the easier and relatively more secure nature of phone apps (I don't think phone apps are that secure, but I think they are more secure than installing random exe's on your computer). If you're willing to install all of the apps, yeah having everything in one place would be convenient, but there's only two or three apps you care about so it's not a huge thing. Moreover most of the phone apps liked to keep things closed. That's just my thinking.
It's also branding. Regular people don't understand clients being separate from protocols being separate from servers. Multiple users sorta need to be on the same XMPP server to talk to each other (yeah there's federated mode but it's a mess), and in modern times there's no way that server isn't run by a huge company that also distributes its own client. And there's no way, controlling both the client and the server, such company will stick to pure XMPP instead of adding tons of proprietary stuff on top to improve the experience and establish control. Hence WhatsApp, FB Messenger, etc were born?
The protocol can be perfect. But unless there are great clients for it on multiple different platforms, and those clients implement all the awesome optional protocol features, it just doesn’t matter.
* Screen sharing
* File sharing
* Sync across devices
* Group chat without fuckery
* Ability to delete and edit messages
* Notifications of new messages
I know XMPP supports all of this and more. But find a cross platform client/server that implements all of it?
Then look at the clients for matrix, telegram, signal, teams, whatsapp, and others.
I forget also how this works when federation is involved. Do both servers need to support those extensions too? I do recall even federation of servers with basic features being painful due to differences in signing and encryption modes.
Btw, iChat used to support all those features, but only when the other side was iChat too.
While the technical problems were certainly one of the main factors contributing to the decline of XMPP, I think that branding was also a big issue. They had a perfectly good name that was gaining traction ("Jabber") and then they suddenly changed it to XMPP, confusing everyone in the process.
Yeah. This wasn't an intentional thing by the community. The "sudden change" was due to the acquisition of Jabber Inc. by Cisco, which included the "Jabber" trademark. There is a trademark agreement with XMPP Standards Foundation to allow open-source projects to apply to use "Jabber" as part of their name. However, unsurprisingly, the community around the protocol rallied around "XMPP" as the safer term, while Cisco moved forward with their "Jabber" product.
I think it has taken too long for the community to realise what an asset a good brand can be, and that it's hard to rally normal users around a protocol and an ecosystem rather than a product. I think that's growing to change though, with a number of user-focused projects around the ecosystem (including Snikket, the one I'm working on).
I can´t find anything regarding Support for multi-device sync there. I don´t know any client which even claims to support something like this.
I only know about MAM which doesn't work with E2EE... and depends on the individual chatroom's server.
> Both XMPP and Matrix have bridges between each other and third-party protocols (proprietary and open ones), which makes any attempt to create false competition between them an unhelpful effort.
Soo first you want E2EE so nobody can tap into your conversations, and then you want to receive text of you messages from the server archive? :hmm emoji:
That is easily possible with XMPP and does not really have anything to do with 'MAM supporting E2EE'. For Message Archive all messages are equal, encrypted or not.
I have the impression that the discussion around XMPP isn't going anywhere. On the one side are the people who say it is outdated and can't handle mobile/multi-device/energy-efficient communication and on the other side are the people who argue, that XMPP got extensions to handle all those cases. I am part of the later group.
However, instead of arguing I think it might be better to give a short summary about the state of XMPP from a users perpective. I use XMPP every day for several years now. In my opinion the best clients are the following:
- Linux -> Gajim (also available for Windows)
- iOS -> Siskin
- Android -> Quicksy/Conversations
Especially Siskin has made great progress over the past year. While these clients can do most of the things you would expect from a modern IM client, there are still a few weak spots:
- The combination of OMEMO (End-to-end encryption) while using multiple (clients over longer periods of time) can lead to situations where some clients can't decrypt messages. This is rarely dramatic (because one of your devices can decrypt the message), but can be annoying.
- It seems video calls across different clients are work-in-progress. Conversations to Conversations works fine, but with Siskin I had some trouble.
So the bottom line is: Most things work fine, but some things don't.
The thing with the Nokia 5800 (I also have one) and other phones not designed in the US is that outside of the US, most people paid for SMS per message. So it made sense to present the messages in that UI, you're paying for the whole thing anyway, could as well use all 160 (or 70 around here) characters. No one in their right mind would split into several messages something that fit into one. For this style of instant messaging, we used ICQ. There were unofficial ICQ clients for just about everything.
On XMPP itself — I'm looking into it as the protocol for messaging for my federated social network. I first contemplated using Matrix, but then I looked at the spec, saw the mathematical notation for the room state synchronization algorithm, and noped outta there really fast.
If you're looking into XMPP for a social network, you might be interested in movim.eu (based on XEP-0277: Microblogging over XMPP) and the efforts to combine ActivityPub and XMPP:
Oh, thanks for this. I did look for a tutorial about implementing a minimally functional Matrix server like there are for ActivityPub[1][2], but didn't find any.
And after reading the whole article, I'd like to add: it really helps to treat these protocols like APIs. As in, if you're building an XMPP server, you wouldn't want to expose the actual clients as resources, for example. You'd instead just send each message to each connected client and present them all as one single "client" to other users and for the purpose of s2s federation. That would eliminate an entire class of issues, like messages getting lost, AND improve the user experience at the cost of a slight, barely noticeable spec noncompliance.
I do a variation of this for ActivityPub in my project already. Except I don't implement c2s ActivityPub at all.
> Everything that we expect today - chat history, reliable message delivery, multi-device synchronization - is an afterthought in XMPP.
The author grossly misunderstands XMPP. The first letter X stands for "eXtensible", and extensible it is.
Chat history, milti-device sync, reliable message delivery is not an afterthought, it is extension (and btw they all are solved problems as of now) The protocol is by design modular, and it is a strength, not weakness.
You can't realistically expect all the world to share the same version of your monolithic messaging protocol. Different instances will support different features, some implementations will lag on with newer features, etc. The only possible answer to this is modularity and legacy fallbacks for some features that are not supported by remote party.
Sure, the protocol could develop more rapidly. I actually believe that XMPP survives despite efforts of the XSF coincils, not thanks to them. However, the core of the protocol is strong and allows to build communication products with UX not worse than Telegram or Discord. And if you lack some crucial feature like a properly working group chat, you can make your own XMPP extension - because eXtensible it is.
In most people's mind extension = optional = afterthought. Especially this is the case if you cannot guarantee that something which supports the protocol actually supports the feature then it's difficult to use that feature. The main point is that the mentioned features are no longer optional for a 'chat protocol', any protocol which does not have them as core or required features is not going to be considered meeting the requirement of 'chat protocol'.
Most people's mind do not care about protocols, they think of products. And speaking of products, every major xmpp server implementation I know (and I know at least five) supports all these features.
Also. You don't really need any of them to send messages between servers. All this stuff matters only for communication between your clients and your own server.
XML is always painful but XMPP brings it to another level by not playing nice with most parsers which expect complete documents, I ended up having to roll my own parser.
But perhaps the situation in XML land has improved since, I sincerely hope so for the people writing today's clients.
Professionally I've been involved in one project that used XMPP as a data protocol between back end services. It was eventually phased out in favor of REST because of buggy libraries which meant capturing messages in queues and replaying whenever the thing fell over.
How old is this article? It talks about client to server encryption like it is some sort of optional thing.
>Today you expect a messenger to be a database.
I do? Not all of us want the levels of resource utilization this approach requires. Why would I want to be able to edit/delete old messages? I can just send new ones.
I said this on a past XMPP thread. It is a dead protocol due to mobile. I loved XMPP but without a push system it is useless on modern mobile operating systems.
> If by "push" you mean sending notifications through 3rd party servers like google's Firebase, I'd like not to use it.
These days there's also UnifiedPush which is an open standard for push on Linux and Android. FluffyChat and SchildiChat (both Matrix clients) support it. I actually switched to SchildiChat from Element because Element's notification service was using too much RAM.
No. Taking the wakelock is significant battery drain. Because of poor mobile OS architecture you have to take the wakelock to leave connections open. On normal Linux you can just have the OS suspend anyway and most of the time the connection will be there when it wakes up and if it doesn't the client automatically reestablishes. (this is exactly how the normal push connection on android is maintained anyway, there's almost no real overhead to having a couple more.)
Mobile push is a combination of brain damage and bizarre propaganda targeting developers.
> Network activity is quite significant for battery drain
It's not activity itself but what app does in background in reaction to incoming packets. Clients I used (Bombus and Xabber) didn't support that XEP with no problem. App may just ignore some stanzas when not needed.
XMPP is widely used on mobile, it has supported push notifications for many years. Without it, you are right, using XMPP on mobile would be pretty painful, but that's not the case.
Indeed, mod_cloud_notify is high on our list of modules to merge for the next Prosody release, if not the highest.
A lot of effort went into Prosody 0.12, which we released recently. It's unfortunate that mod_cloud_notify didn't quite make the cut for that version, but it was better than delaying the long overdue release even further. The vast majority of work on Prosody is unpaid volunteer time, and as with most open-source work there are certain kinds of tasks which are hard to find funding for, leading to the old "it'll be done when it's done" because we (the developers) simultaneously need to pay our bills.
Also, in recognition of many desirable things being in community modules, one thing we did prioritize in 0.12 was the plugin installer, which should make it easier for people to add additional modules to their Prosody installation.
Client to server protocol is unimportant, you could as well roll your own that suits your use case. I do feel like XMPP is a good server-to-server protocol for federated instant messaging though. The only other one I know is Matrix, and it takes a much more convoluted approach by adding the requirement that each "room" is fully distributed across all participating servers. While it's something that's nice to have, it's not worth the hassle, imo.
It would be just as easy to write a post like this about JSON, Matrix and so on. Both have many warts.
But I really don't much care. No technology is perfect, and there will always be people who dislike choices that other people have made. What matters is what we do with the technology. XMPP has proven itself able to evolve over more than two decades, during which the internet and the way we use it has shifted dramatically, and yet it continues to be relevant as new people discover and adopt it.
It's unfair to describe things like multi-device sync as "afterthoughts" when XMPP was one of the first real-time messaging protocols to have support for multiple concurrent connections of the same account built in, at a time before the iPhone was released, and most people had a single device with wired access to the internet only.
Support for multi-device sync is part of the suite of protocol features required by modern XMPP implementations, these requirements are updated every year to account for the changing technology landscape: https://xmpp.org/about/compliance-suites/
I personally like the simple delivery model of XMPP compared to the "distributed database" model that Matrix pursues. I think there are use-cases for both approaches. Both XMPP and Matrix have bridges between each other and third-party protocols (proprietary and open ones), which makes any attempt to create false competition between them an unhelpful effort. What's important is that both provide openly-documented protocols with open-source reusable implementations, and (in my opinion) most important of all: decentralized open communication networks.
The problems facing the broader adoption of open networks for modern messaging are not protocol problems.