13 ms·

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, a

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/ 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.

dmitriid 4y ago
> 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. I still remember "The State of Mobile XMPP in 2016", https://gultsch.de/xmpp_2016.html https://gultsch.de/xmpp_2016.html At the time, 9 years after iPhone had come on the scene, most modern features were still experimental draft proposals implemented by no one. 5 more years later there's maybe one client that implements the modern features (Conversations for Android IIRC), and that's about it. And it's an unknown how many servers implement those features.
- seba_dos1 4y ago
  > 5 more years later there's maybe one client that implements the modern features (Conversations for Android IIRC), and that's about it. ...and yet I'm using three different modern clients that work well with each other. > And it's an unknown how many servers implement those features. Enough to make me not have to care about it.
- MattJ100 4y ago
  > And it's an unknown how many servers implement those features It's not: https://compliance.conversations.im/tests/ https://compliance.conversations.im/tests/ 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/ https://providers.xmpp.net/ and https://joinjabber.org/ 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.
ajconway 4y ago
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.
- olah_1 4y ago
  > 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.
  - wusspuss 4y ago
    How much worse than XMPP is Matrix in this regard? On XMPP your and your interlocutor's server can see who you talk to
    - zaik 4y ago
      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.
- Zash 4y ago
  Maybe the key is network effect and enough marketing to bootstrap it?
  - ajconway 4y ago
    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.
    - 4y ago
wusspuss 4y ago
>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
- anonymoushn 4y ago
  > 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. I guess you're not using Discord.
- MattJ100 4y ago
  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).
wusspuss 4y ago
>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.
- progval 4y ago
  > JSON has no namespaces Causing all extensible JSON-based protocols to eventually reinvent them: * https://www.w3.org/TR/json-ld11/#compact-iris https://www.w3.org/TR/json-ld11/#compact-iris * "If new events are added, the event type key SHOULD follow the Java package naming convention, e.g. com.example.myapp.event." https://spec.matrix.org/v1.2/client-server-api/#types-of-room-events https://spec.matrix.org/v1.2/client-server-api/#types-of-roo... * https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-22#section-8.1 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-22... (no aliases, so it's even more verbose) * https://github.com/OAI/OpenAPI-Specification/issues/1362#issuecomment-336430627 https://github.com/OAI/OpenAPI-Specification/issues/1362#iss...
  - wusspuss 4y ago
    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 <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls> 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
xeeeeeeeeeeenu 4y ago
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.
- MattJ100 4y ago
  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).
InfiniteRand 4y ago
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.
- hot_gril 4y ago
  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?
TedDoesntTalk 4y ago
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.
- deleted 4y ago
  [deleted]
- hot_gril 4y ago
  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.
- olah_1 4y ago
  > I know XMPP supports all of this and more. But find a cross platform client/server that implements all of it? That is what Snikket is trying to be. https://github.com/snikket-im https://github.com/snikket-im
hot_gril 4y ago
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...
- Andrew_nenakhov 4y ago
  > XML is needlessly complicated 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.
  - wusspuss 4y ago
    >For messaging purposes, it is absolutely identical to JSON in this regard. There's no "JSON mindset" to produce anything comparable to this crime against bandwidth and code brevity: <stream:stream from="draugr.de" id="{ID}" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client"> 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.
tcfhgj 4y ago
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. Bridges don't really work with E2EE anymore...
- Andrew_nenakhov 4y ago
  > MAM which doesn't work with E2EE... 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:
  - tcfhgj 4y ago
    no, I just want multi device sync like what WhatsApp and Matrix offers
    - Andrew_nenakhov 4y ago
      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.
      - tcfhgj 4y ago
        then tell me with what constellation of apps this actually works
        Andrew_nenakhov 4y ago
        Web/iOS versions of Xabber do it quite well, complete with videocalls and screensharing, etc. Android version is in rewrite (decided to dump existing app because of tech debt issues), but I have zero reasons to doubt that it will work (hopefully by august). iOS version is not yet released on Appstore because we need to work out some more issues (not too many), but I can give you access to it, if you're interested.

dmitriid 4y ago

> 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. I still remember "The State of Mobile XMPP in 2016", https://gultsch.de/xmpp_2016.html https://gultsch.de/xmpp_2016.html At the time, 9 years after iPhone had come on the scene, most modern features were still experimental draft proposals implemented by no one. 5 more years later there's maybe one client that implements the modern features (Conversations for Android IIRC), and that's about it. And it's an unknown how many servers implement those features.

seba_dos1 4y ago
> 5 more years later there's maybe one client that implements the modern features (Conversations for Android IIRC), and that's about it. ...and yet I'm using three different modern clients that work well with each other. > And it's an unknown how many servers implement those features. Enough to make me not have to care about it.
MattJ100 4y ago
> And it's an unknown how many servers implement those features It's not: https://compliance.conversations.im/tests/ https://compliance.conversations.im/tests/ 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/ https://providers.xmpp.net/ and https://joinjabber.org/ 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.

ajconway 4y ago

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.

olah_1 4y ago
> 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.
- wusspuss 4y ago
  How much worse than XMPP is Matrix in this regard? On XMPP your and your interlocutor's server can see who you talk to
  - zaik 4y ago
    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.
Zash 4y ago
Maybe the key is network effect and enough marketing to bootstrap it?
- ajconway 4y ago
  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.
  - 4y ago

wusspuss 4y ago

>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

anonymoushn 4y ago
> 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. I guess you're not using Discord.
MattJ100 4y ago
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).

wusspuss 4y ago

>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.

progval 4y ago
> JSON has no namespaces Causing all extensible JSON-based protocols to eventually reinvent them: * https://www.w3.org/TR/json-ld11/#compact-iris https://www.w3.org/TR/json-ld11/#compact-iris * "If new events are added, the event type key SHOULD follow the Java package naming convention, e.g. com.example.myapp.event." https://spec.matrix.org/v1.2/client-server-api/#types-of-room-events https://spec.matrix.org/v1.2/client-server-api/#types-of-roo... * https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-22#section-8.1 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-22... (no aliases, so it's even more verbose) * https://github.com/OAI/OpenAPI-Specification/issues/1362#issuecomment-336430627 https://github.com/OAI/OpenAPI-Specification/issues/1362#iss...
- wusspuss 4y ago
  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 <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls> 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

xeeeeeeeeeeenu 4y ago

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.

MattJ100 4y ago
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).

InfiniteRand 4y ago

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.

hot_gril 4y ago
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?

TedDoesntTalk 4y ago

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.

deleted 4y ago
[deleted]
hot_gril 4y ago
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.
olah_1 4y ago
> I know XMPP supports all of this and more. But find a cross platform client/server that implements all of it? That is what Snikket is trying to be. https://github.com/snikket-im https://github.com/snikket-im

hot_gril 4y ago

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...

Andrew_nenakhov 4y ago
> XML is needlessly complicated 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.
- wusspuss 4y ago
  >For messaging purposes, it is absolutely identical to JSON in this regard. There's no "JSON mindset" to produce anything comparable to this crime against bandwidth and code brevity: <stream:stream from="draugr.de" id="{ID}" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client"> 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.

tcfhgj 4y ago

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. Bridges don't really work with E2EE anymore...

Andrew_nenakhov 4y ago
> MAM which doesn't work with E2EE... 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:
- tcfhgj 4y ago
  no, I just want multi device sync like what WhatsApp and Matrix offers
  - Andrew_nenakhov 4y ago
    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.
    - tcfhgj 4y ago
      then tell me with what constellation of apps this actually works
      - Andrew_nenakhov 4y ago
        Web/iOS versions of Xabber do it quite well, complete with videocalls and screensharing, etc. Android version is in rewrite (decided to dump existing app because of tech debt issues), but I have zero reasons to doubt that it will work (hopefully by august). iOS version is not yet released on Appstore because we need to work out some more issues (not too many), but I can give you access to it, if you're interested.