Difference between revisions of "XMPP 2.0"

From XMPP WIKI
Jump to navigation Jump to search
m (→‎Current situation: get the quotes right)
(New Session Initiation idea)
Line 48: Line 48:


None needed. Chat conversations work fine without any resource locking today.
None needed. Chat conversations work fine without any resource locking today.
== Client Session Setup ==
=== Current situation ===
A client that (re)connects to its server needs to perform these steps:
# Authenticate (actually: establish an XML stream, convert to TLS, establish a new XML stream, perform SCRAM or some other multi-step auth mechanism)
# Attempt [https://xmpp.org/extensions/xep-0198.html#resumption Stream Resumption]. On success, it is done, on failure it needs to continue:
# bind a new session
# Enable Carbons
# Send initial presence
# Obtain offline messages
# (optionally) query the MAM archive and deduplicate with offline messages
# Join MUCs
There is a race condition between enabling Carbons and synchronizing MAM, and the number of steps and round-trips is tremendous.
=== XMPP 2.0 Session Initiation ===
The client and server must coordinate the required information for a sync as soon as possible:
# Authenticate
# Client sends a bind2 request containing:
#* stream resumption id (optional, to faciliate Stream Resumption)
#* last-known MAM message-id (optional, to achieve full synchronization)
#* MAM request with a time-delta (optional, alternative to message-id if only the history of the last N time units is needed)
#* initial presence (maybe?)
#* MUCs to join (maybe?)
# The server automagically figures out whether to do a stream resumption or a MAM sync and provides according data to the client, generates presence broadcast accordingly

Revision as of 17:00, 10 August 2017

This page summarizes a few ideas on things which could/should/may be in an eventual XMPP 2.0.

This page is a draft written by individuals who may or may not be XSF members. It does not necessarily reflect the view or intention of XSF Board, Council or the XSF as organization as a whole, if that’s a thing.

 Issues existing in XMPP 1.0

Routing rules

Current situation

The routing rules for stanzas addressed to the bare JID as defined in RFC 6120 are blurry and don’t really match modern "always-online but not necessarily in the view of the user" multi-device use cases. This is why Message Carbons (XEP-0280) have been invented. They allow a device to tell the server that it wants to receive carbon-copies of all messages received by any resource of an account. This only affects typical chat-related <message/> stanzas (there are exceptions for certain message types; for presence, there is a well-defined broadcast-to-all-resources mechanism; and IQs can only be addressed to a single resource).

However, throughout the history of XMPP, there have been XEPs which use messages to send data which is really only of interest for a single resource. Prime examples are In-Band Bytestreams (XEP-0047), privacy enhancing protocols such as the (in)famous OTR and (private messages from) Multi-User Chat (XEP-0045). This led to Message Carbon rules being hand-wavy and blurry, some of the behaviour being implementation-defined, depending on co-operating clients which do not speak Message Carbons themselves and other unfortunaties.

Proposed change

To make things simpler, routing rules (for messages) could be re-defined to the following:

  • If a message is addressed to a bare account JID, it is delivered to all online resources of the JID.
  • If a message is addressed to a full JID:
    • if an online resource exists at that full JID, the message is delivered to that resource
    • if no online resource exists, an error is returned (NOTE: privacy implications and possible resource scanning need to be thought through)

In addition, resource locking as described in RFC 6121 would be discouraged and deprecated, since it interferes with these rules. See below for considerations on resource locking.

Migration path in a hypothetical XMPP 2.0 Session

The server(s) would translate the semantics for non-XMPP-2.0 servers and clients. For this, the following transformations would be applied when talking to non-XMPP-2.0 nodes:


Resource locking

Current situation

RFC 6121, Section 5.1 and XEP-0296 describe the process of resource locking for one-on-one chats. In essence, once a response is received from a peer resource, the following messages must be sent to that resource.

The intent was that messages would always arrive at the device currently used by the conversation partner (since Message Carbons were not there), because the routing rules for message stanzas did not enforce that behaviour.

Furthermore, the features offered to a user are often limited by clients based on the capabilities (e.g. Last Message Correction) of the locked-to resource. This introduces race conditions and incompatibility when the chat partner switches devices or reads up the conversation from an offline storage / archive.

Proposed change

Eliminate resource locking in XMPP 2.0 entirely. Instead, always send conversational content to the bare JID. Messages sent to the full JID in XMPP 2.0 are specifically addressed to the resource and will not be carbon-copied, as described in the previous section.

Migration path in a hypothetical XMPP 2.0 Session

None needed. Chat conversations work fine without any resource locking today.

Client Session Setup

Current situation

A client that (re)connects to its server needs to perform these steps:

  1. Authenticate (actually: establish an XML stream, convert to TLS, establish a new XML stream, perform SCRAM or some other multi-step auth mechanism)
  2. Attempt Stream Resumption. On success, it is done, on failure it needs to continue:
  3. bind a new session
  4. Enable Carbons
  5. Send initial presence
  6. Obtain offline messages
  7. (optionally) query the MAM archive and deduplicate with offline messages
  8. Join MUCs

There is a race condition between enabling Carbons and synchronizing MAM, and the number of steps and round-trips is tremendous.

XMPP 2.0 Session Initiation

The client and server must coordinate the required information for a sync as soon as possible:

  1. Authenticate
  2. Client sends a bind2 request containing:
    • stream resumption id (optional, to faciliate Stream Resumption)
    • last-known MAM message-id (optional, to achieve full synchronization)
    • MAM request with a time-delta (optional, alternative to message-id if only the history of the last N time units is needed)
    • initial presence (maybe?)
    • MUCs to join (maybe?)
  3. The server automagically figures out whether to do a stream resumption or a MAM sync and provides according data to the client, generates presence broadcast accordingly