3 ms·

> XMPP doesn't (to my knowledge) have any good, standardized way of dealing with offline communications and catching up with messages. XEP-0313: Message Archiv

> XMPP doesn't (to my knowledge) have any good, standardized way of dealing with offline communications and catching up with messages. XEP-0313: Message Archive Management https://xmpp.org/extensions/xep-0313.html https://xmpp.org/extensions/xep-0313.html > This document defines a protocol to query and control an archive of messages stored on a server. Since 2012. Implemented in all the major servers and clients for at least 5 to 10 years now.

kitkat_new 4y ago
> XEP-0313: Message Archive Management https://xmpp.org/extensions/xep-0313.html https://xmpp.org/extensions/xep-0313.html" he said "good" MAM does not work with encryption and multiple devices, it relies on potentially different servers for each room -> other server goes down -> part of your history is lost, it is only for MUCs
- MattJ100 4y ago
  > MAM does not work with encryption and multiple devices False. MAM is explicitly designed for use with multiple devices. OMEMO is fully compatible with MAM and multiple devices too. > it relies on potentially different servers for each room In XMPP, as deployed on the public network, each group is responsible for hosting its own data. That is, they do not replicate the group data and state between all federating servers that are part of the group in the way Matrix does. If the group goes down permanently and you do not have the history from the group saved locally in your client, you are correct that the data for that group is lost. Most XMPP clients default to keeping history on the user's device, rather than treating the server as a permanently available source of history. My experience is that this is good enough for most people, and the extra complexity of fully replicating groups is not necessary for the average person. That's not to say it doesn't have some uses (for which XMPP does have solutions, such as FMUC, they just aren't usually implemented or deployed on the public network - https://www.isode.com/whitepapers/federated-muc.html https://www.isode.com/whitepapers/federated-muc.html ). > it is only for MUCs This is also false, as you can see from even a cursory reading of the spec.
  - kitkat_new 4y ago
    > False. MAM is explicitly designed for use with multiple devices. OMEMO is fully compatible with MAM and multiple devices too. please expand on how OMEMO encrypted messages land readable on other devices of you through MAM > If the group goes down permanently = certain single server in the group > My experience is that this is good enough for most people In mine it isn't when virtually anyone is (supposed to be) able to run a server, which he might abandon due to lost interest or might fail due to unprofessional maintenance. > This is also false, as you can see from even a cursory reading of the spec. you take that point
    - Semaphor 4y ago
      > please expand on how OMEMO encrypted messages land readable on other devices of you through MAM Not GP, and I don’t know how it works technically, but I can confirm that OMEMO encrypted messages sync to other devices when I come back online there.
    - MattJ100 4y ago
      > certain single server in the group To be clear, only the server that the group is hosted on. Servers are not "in groups", so your statement doesn't make sense. > please expand on how OMEMO encrypted messages land readable on other devices of you through MAM MAM is a feature of XMPP that provides a way to query all incoming and outgoing messages, including those received while the client was offline. OMEMO is a many-to-many end-to-end encryption protocol. Whether a message is delivered while a client is connected, or later via synchronization after a period of disconnection, doesn't have any effect on the encryption or ability of a client to decrypt the message. These things can all be verified by reading the specs or simply using any modern XMPP client and observing it work for yourself.
      - kitkat_new 4y ago
        > To be clear, only the server that the group is hosted on. Fullstop > Whether a message is delivered while a client is connected, or later via synchronization after a period of disconnection, doesn't have any effect on the encryption or ability of a client to decrypt the message. what about when a client creates a fresh connection and I want to read my messages on it?

kitkat_new 4y ago

> XEP-0313: Message Archive Management https://xmpp.org/extensions/xep-0313.html https://xmpp.org/extensions/xep-0313.html" he said "good" MAM does not work with encryption and multiple devices, it relies on potentially different servers for each room -> other server goes down -> part of your history is lost, it is only for MUCs

MattJ100 4y ago
> MAM does not work with encryption and multiple devices False. MAM is explicitly designed for use with multiple devices. OMEMO is fully compatible with MAM and multiple devices too. > it relies on potentially different servers for each room In XMPP, as deployed on the public network, each group is responsible for hosting its own data. That is, they do not replicate the group data and state between all federating servers that are part of the group in the way Matrix does. If the group goes down permanently and you do not have the history from the group saved locally in your client, you are correct that the data for that group is lost. Most XMPP clients default to keeping history on the user's device, rather than treating the server as a permanently available source of history. My experience is that this is good enough for most people, and the extra complexity of fully replicating groups is not necessary for the average person. That's not to say it doesn't have some uses (for which XMPP does have solutions, such as FMUC, they just aren't usually implemented or deployed on the public network - https://www.isode.com/whitepapers/federated-muc.html https://www.isode.com/whitepapers/federated-muc.html ). > it is only for MUCs This is also false, as you can see from even a cursory reading of the spec.
- kitkat_new 4y ago
  > False. MAM is explicitly designed for use with multiple devices. OMEMO is fully compatible with MAM and multiple devices too. please expand on how OMEMO encrypted messages land readable on other devices of you through MAM > If the group goes down permanently = certain single server in the group > My experience is that this is good enough for most people In mine it isn't when virtually anyone is (supposed to be) able to run a server, which he might abandon due to lost interest or might fail due to unprofessional maintenance. > This is also false, as you can see from even a cursory reading of the spec. you take that point
  - Semaphor 4y ago
    > please expand on how OMEMO encrypted messages land readable on other devices of you through MAM Not GP, and I don’t know how it works technically, but I can confirm that OMEMO encrypted messages sync to other devices when I come back online there.
  - MattJ100 4y ago
    > certain single server in the group To be clear, only the server that the group is hosted on. Servers are not "in groups", so your statement doesn't make sense. > please expand on how OMEMO encrypted messages land readable on other devices of you through MAM MAM is a feature of XMPP that provides a way to query all incoming and outgoing messages, including those received while the client was offline. OMEMO is a many-to-many end-to-end encryption protocol. Whether a message is delivered while a client is connected, or later via synchronization after a period of disconnection, doesn't have any effect on the encryption or ability of a client to decrypt the message. These things can all be verified by reading the specs or simply using any modern XMPP client and observing it work for yourself.
    - kitkat_new 4y ago
      > To be clear, only the server that the group is hosted on. Fullstop > Whether a message is delivered while a client is connected, or later via synchronization after a period of disconnection, doesn't have any effect on the encryption or ability of a client to decrypt the message. what about when a client creates a fresh connection and I want to read my messages on it?