Flow/Server based 1-1 chat state

From XMPP WIKI
Jump to navigation Jump to search

Server based 1-1 chat state

(or: "persistent 1-1 chats involving multiple clients")

Intro

Toolkit:

  1. MAM
  2. MR2 (or Carbons)
  3. MID

Findings

  1. XMPP-IM (RFC 6121 8.) Message routing is obstructive to achieve the goal
  2. Clients are able to determine the MAM ID before they send the message
  3. It's a good idea to keep the state after stream resumption
  4. More message types need to be forked for incoming and outgoing messages, not just chat (as it's currently done by the carbons XEP).
  5. Forked and forwarded messages should possible be queued when the receiving client is inactive (e.g. by means of CSI)

Questions

  1. Do we want to add more semantic to an xep198 ack? E.g. "has been added to the archive"?

Sketch

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 should probably mean 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 MAM IDs of different entities are not identical. Romeo and Julia store the same message in their MAM Archive under different IDs
  • All involved clients use MAM to fetch (and 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 message known to be archived, using the Message ID of that message. From a clients perspective, the last message known to e archived is either the last incoming message (with a MAM ID), or the last send message by that client, for which the client calculated the message ID, that got xep198 ack'ed.

Carbons vs. MR2. vs Goal

Description Carbons MR2 Goal
Forks incoming just chat all but groupchat and error all but groupchat, error and headline
Forks outgoing just chat just chat all but groupchat and error (?)
Can be disabled Yes No No
State preserved after SM resumption not (clearly) specified Yes Yes
Designed as Property of the stream controlled via IQs Stream feature Stream feature
Retrieved from "https://wiki.xmpp.org/web/index.php?title=Flow/Server_based_1-1_chat_state&oldid=1896"