5 ms·

""" Matrix is a decentralised conversation history replication protocol, not a messaging protocol. Architecturally it has no concept of direct messages or store

""" Matrix is a decentralised conversation history replication protocol, not a messaging protocol. Architecturally it has no concept of direct messages or store-and-forward messaging for IM; instead everything is a group conversation with a conversation history getting replicated between servers (and their clients). Conversely, XMPP is a message passing system (although it's true you could layer a DAG-based conversation database on top in a XEP, at the expense of compatibility with the rest of XMPP). It's literally the difference between NNTP (Matrix) and SMTP+IMAP (XMPP). """ This is how Matrix solved my problems right away and why XMPP never actually understood or cared about my problems. I want all my messages and history on all my devices wherever I login with the proper credentials.... not a handwavey reference to 3 different ways to implement that with 9-15 different XEP combinations which noone has done yet. TLS/crypto and the federation on top are great/mandatory but Matrix solved the core problem first and thats what matters. Thanks again btw :)

olah_1 5y ago
> I want all my messages and history on all my devices wherever I login with the proper credentials Is this not possible with XMPP? Genuine question. I thought there were recent XEPs for standardized handling of message history (including export/import). edit: it’s here https://xmpp.org/extensions/xep-0313.html#intro https://xmpp.org/extensions/xep-0313.html#intro
- kitkat_new 5y ago
  iirc, MAM doesn't work with encryption and depends on support by the server a specific room is hosted on (duration and availability)
- MattJ100 5y ago
  Correct, it's been possible for many years. What's generally the case is that people complaining about things like this are still using/remembering software that hasn't changed much in the last decade. Common culprits are Pidgin and Adium (both based on libpurple) which, while still developed, is lacking many modern features. I'm hoping that will change, but it's subject to the usual economics of open-source. XMPP is between a group of people who complain that it is stuck in the past (i.e. they think it still only supports the features it supported in 2008) and another group of people who complain the opposite - that it has "too many XEPs" (this is due the fact that XMPP evolves through a mechanism of creating and deprecating extensions to the core protocol). In reality the XSF annually publishes the current list of recommended XEPs for different use cases (see https://xmpp.org/about/compliance-suites/ https://xmpp.org/about/compliance-suites/ ) and the XEPs for multi-device messaging have been part of this set for many years, and are implemented in practically every actively maintained XMPP client.
  - olah_1 5y ago
    Ironically, Matrix MSCs will have the same exact “problem” of “too many extensions”.
    - Arathorn 5y ago
      No, the whole point of MSCs is that they aren't part of the protocol - they are just random proposals for new ideas; the more the merrier. The protocol doesn't have extensions.
      - olah_1 5y ago
        When an MSC makes it through the process, it is added to the protocol, right? Then all the servers and clients need to implement those MSCs or else they are not compliant with the protocol. Either you're not compliant with the protocol (Matrix), or you're not compliant with a certain extension (XMPP). I don't understand how these are different. Matrix has a lot of non-compliant servers and clients. XMPP has a lot of servers and clients that don't implement certain extensions.
        Arathorn 5y ago
        > When an MSC makes it through the process, it is added to the protocol, right? Yes. > Then all the servers and clients need to implement those MSCs or else they are not compliant with the protocol. It's no longer a MSC at that point; it's part of the next versioned release of the protocol. So yeah, if the feature profile their client/server is targeting doesn't implement the required features from that version of the protocol, it's not compliant. > Either you're not compliant with the protocol (Matrix), or you're not compliant with a certain extension (XMPP). > I don't understand how these are different. Matrix has a lot of non-compliant servers and clients. XMPP has a lot of servers and clients that don't implement certain extensions. The difference is that in Matrix there's only one specification which servers & clients can be compliant or not compliant with. Whereas in XMPP, there's an arbitrary combinatoric explosion of XEPs which you may or may not be compliant with.

olah_1 5y ago

> I want all my messages and history on all my devices wherever I login with the proper credentials Is this not possible with XMPP? Genuine question. I thought there were recent XEPs for standardized handling of message history (including export/import). edit: it’s here https://xmpp.org/extensions/xep-0313.html#intro https://xmpp.org/extensions/xep-0313.html#intro

kitkat_new 5y ago
iirc, MAM doesn't work with encryption and depends on support by the server a specific room is hosted on (duration and availability)
MattJ100 5y ago
Correct, it's been possible for many years. What's generally the case is that people complaining about things like this are still using/remembering software that hasn't changed much in the last decade. Common culprits are Pidgin and Adium (both based on libpurple) which, while still developed, is lacking many modern features. I'm hoping that will change, but it's subject to the usual economics of open-source. XMPP is between a group of people who complain that it is stuck in the past (i.e. they think it still only supports the features it supported in 2008) and another group of people who complain the opposite - that it has "too many XEPs" (this is due the fact that XMPP evolves through a mechanism of creating and deprecating extensions to the core protocol). In reality the XSF annually publishes the current list of recommended XEPs for different use cases (see https://xmpp.org/about/compliance-suites/ https://xmpp.org/about/compliance-suites/ ) and the XEPs for multi-device messaging have been part of this set for many years, and are implemented in practically every actively maintained XMPP client.
- olah_1 5y ago
  Ironically, Matrix MSCs will have the same exact “problem” of “too many extensions”.
  - Arathorn 5y ago
    No, the whole point of MSCs is that they aren't part of the protocol - they are just random proposals for new ideas; the more the merrier. The protocol doesn't have extensions.
    - olah_1 5y ago
      When an MSC makes it through the process, it is added to the protocol, right? Then all the servers and clients need to implement those MSCs or else they are not compliant with the protocol. Either you're not compliant with the protocol (Matrix), or you're not compliant with a certain extension (XMPP). I don't understand how these are different. Matrix has a lot of non-compliant servers and clients. XMPP has a lot of servers and clients that don't implement certain extensions.
      - Arathorn 5y ago
        > When an MSC makes it through the process, it is added to the protocol, right? Yes. > Then all the servers and clients need to implement those MSCs or else they are not compliant with the protocol. It's no longer a MSC at that point; it's part of the next versioned release of the protocol. So yeah, if the feature profile their client/server is targeting doesn't implement the required features from that version of the protocol, it's not compliant. > Either you're not compliant with the protocol (Matrix), or you're not compliant with a certain extension (XMPP). > I don't understand how these are different. Matrix has a lot of non-compliant servers and clients. XMPP has a lot of servers and clients that don't implement certain extensions. The difference is that in Matrix there's only one specification which servers & clients can be compliant or not compliant with. Whereas in XMPP, there's an arbitrary combinatoric explosion of XEPs which you may or may not be compliant with.