145
edits
Difference between revisions of "XMPP 2.0"
Jump to navigation
Jump to search
New Session Initiation idea
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 | |||