Difference between revisions of "Flow/Server based 1-1 chat state"

From XMPP WIKI
Jump to navigation Jump to search
 
(4 intermediate revisions by the same user not shown)
Line 18: Line 18:
# Clients are able to determine the MAM ID before they send the message
# Clients are able to determine the MAM ID before they send the message
# It's a good idea to keep the state after stream resumption
# It's a good idea to keep the state after stream resumption
# More message types need to be forked for incoming and outgoing messages, not just chat.
# More message types need to be forked for incoming and outgoing messages, not just chat (as it's currently done by the carbons XEP).
# Forked and forwarded messages should possible be queued when the receiving client is inactive (e.g. by means of CSI)
# Forked and forwarded messages should possible be queued when the receiving client is inactive (e.g. by means of CSI)


Line 32: Line 32:
* When the message arrives at Julia clients, it will contain the MAM ID under which it was stored in Julia's MAM Archive
* 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).
* 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
* 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)
** 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.
** 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
* 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 display those parts of the conversation happened while they where offline
* 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.
* 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.


Line 63: Line 63:
|-
|-
| State preserved after SM resumption
| State preserved after SM resumption
| No
| not (clearly) specified
| Yes
| Yes
| Yes
| Yes
|-
| Designed as
| Property of the stream controlled via IQs
| Stream feature
| Stream feature
|}
|}

Latest revision as of 08:36, 12 August 2015

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