Flow/Server based 1-1 chat state
Server based 1-1 chat state
(or: "persistent 1-1 chats involving multiple clients")
- MR2 (or Carbons)
- XMPP-IM (RFC 6121 8.) Message routing is obstructive to achieve the goal
- Clients are able to determine the MAM ID before they send the message
Romeo and Julia want to talk. They both have multiple clients (desktop, mobile device, etc), and they expect that their conversation is completely available on each of their devices.
- If Romeo sends a message to Julia, the message is forked to all other clients of Romeo, and to all clients of Julia
- When the message arrives at Julia clients, it will contain the MAM ID under which it was stored in Julia's MAM Archive
- Romeo is able to calculate the MAM ID under which the message was stored in his MAM Archive, by concatenating the Message ID with the Stream ID (or another suitable ID told to Romeo's client).
- A Stream Management ack means that ack'ed messages have been added to the users MAM archive
- It's currently undefined what should happen if the message could not be added (e.g. because the archive storage's space is full)
- I'd expect impls to somehow indicate the MAM error but continue to process the message. That is route and SM ack it.
- Those two MAM IDs are not identical. Romeo and Julia store the same message in their MAM Archive under different IDs
- All involved clients use MAM to display those parts of the conversation happened while they where offline
- If a client connects, it requests the MAM archived messages starting from the last time a MAM archived messaged was received, using the Message ID of that message.
Carbons vs. MR2. vs Goal
|Forks incoming||just chat||all but groupchat and error||all message types
(maybe even headline, if it would not be send otherwise)
|Forks outgoing||just chat||just chat||all but groupchat and error (?)|
|Can be disabled||Yes||No||No|
|State preserved after SM resumption||No||Yes||Yes|